Q: What is Process Rights Management? A: Process Rights Management does away with the traditional split between the all-powerful Superuser and ordinary users. Rather than relying on testing the effective uid for actions that used to be reserved for the Super-user only, in the Solaris 10 OS, we test for the effective privilege. As a result, processes that need to do one specific, privileged thing no longer need to start or run as root; rather, they can run under any uid with just a few privileges added. There are no longer two classes of process: those run by root and the others. You can have ordinary user processes as before, or run them with a few additional privileges. You can have all-powerful processes as before, but you can also run them with fewer privileges. Q: So "su" and ordinary uid 0 processes no longer work? A: No, Sun believes strongly in backward compatibility; the backward compatibility is somewhat complicated, but it has been designed to be safe. That is, you cannot use the backward compatibility mode to leverage a handful of privileges into all privileges. We now simply have two types of processes: "Privilege Aware" processes and "Non Privilege Aware" processes. Transition between the two types is largely automatic. See the entry in my blog describing the mechanism in more detail. Q: This sounds very much like an enabling technology which allows you to run processes with fewer privileges; has the Solaris OS been modified to take advantage of this? A: Yes; quite a few programs and processes have been modified to take advantage of fine-grained privileges. For example, traditionally set-uid programs like ufsdump, ufsrestore, rsh, rlogin, rdist, rcp, ping, traceroute, w and uptime now run with just the privileges they need. A number of daemons (rpcbind, nfsd, lockd, mountd, and more) run with a reduced set of privileges and/or a non-root uid. We've also used this for our own "privilege separated" implementation of sshd. The superuser in a zone is also kept in check using privileges; this superuser has fewer privileges than the superuser in the global zone. And we've even made a few operations privileged, which used to be unprivileged. You can now effectively prohibit users from seeing processes owned by others, prevent processes from ever fork()ing or exec()ing again, and prevent users from making hard links to files they do not own. Q: Why is RBAC so hard to set up and mysterious about why it doesn't do what you think it should, i.e. setting up /usr/local/bin/some_cmd to run as root for user bob who is a member of priv_users profile. This ought to be trivial, but it does not work, and what is more, it doesn't tell me why it doesn't work. Is there a log file/debug mode? A: The first command to learn when doctoring with RBAC is probably "profiles -l". This will show you the list of active profiles, the order in which they are tried, and the commands that are part of the profile and the uid and privileges they run with. The reason why "nothing happens" in some cases is that generally we fall back to "*" in the "All" profiles. The command then runs without any additional rights. The last thing to realize is that RBAC will resolve the symbolic links in a pathname to get to a canonical version of the pathname. It is that pathname which is then matched against the RBAC database. Perhaps this is the most surprising feature; this often causes a mismatch against the database and that makes it looks like RBAC does not work. Q: Is it possible to grant the privileges to a process allowing it to listen on a /specific/ reserved (<1024) port? Example: running an rsync daemon on port 873 as non-superuser but not letting it use any other reserved ports. A: No; the privilege system replaces the old "suser" checks and only works on the granularity of a single class of objects, and not on single objects. However, sufficient mechanisms are now available in the Solaris OS to create a tool that implements such a fine-grained form of access control. Q: What is being done to address heap overflows and return to libc type vulnerabilities? The stack overflow protection that ships with Solaris is trivial to get around, and process rights management won't protect applications in all situations. Is there anything being looked at to address the plethora of attack vectors (format string, integer overflows, stack overflows and heap overflows) that are being exploited in poorly written software? Are there any attempts to address this in libc (with propolice, for example) or at runtime? OpenBSD has solved a good deal of these issues, and I would _LOVE_ for my favorite OS (Solaris) to address them as well. A: Well, this session is about process right management, first and foremost. Privileges help make your systems less vulnerable in that daemons can run with fewer privileges, even fewer than ordinary processes had in the Solaris 9 OS and before. For example, a process can run without the exec privilege so that a buffer overflow cannot be used to start another program. Your exploit needs to be fully self-contained and run inside the attacked program. Also, the Limit set can be used to prevent subprocesses from exploiting other holes in the OS, as processes that are limited too much cannot execute set-uid root programs and gain privileges. Similarly, set-uid root programs have been re-written to run with as few privileges as needed, further reducing the risk. Closer to the point of your question: one of the things we did for Solaris on x86 platforms is that the use of the NX so mmap (~PROT_EXEC) now just works. We've taken this a bit further than on SPARC; on SPARC the PLT needs to be executable. Not so on x86, so for AMD64 binaries as well as binaries shipped with the Solaris OS, we now default to non-executable data and bss segments, i.e., there's precious little data which you can actually execute. Among the issues we face with randomizing the data segments are things like debuggability, observability, reproducibility, performance, and the (limited) amount of virtual memory available in 32-bit processes. We're certainly studying some of the work done by others. I wouldn't necessarily go as far as saying OpenBSD "solved" these problems; it may have made them considerably harder. (For your typical daemon that forks, you get many tries to guess the proper layout of the memory.) Q: How do privileges relate to RBAC authorizations? A: Privileges are one of the kernel mechanisms RBAC uses to allow properly authorized users to run certain programs with additional rights. In the Solaris 8 and 9 OS, these additional rights are limited to a different user id (usually 0) or a different group id. In the Solaris 10 OS we allow privileges to be granted or taken away in several ways through RBAC:
- To individual users on login in "user_attr" So privileges are one part of the OS used by RBAC to run processes with elevated rights. Q: After I create a user with admin capability, can I completely remove both the UID 0 and the user name root, so my OS has no user with name root, and no ID has the number 0? A: The "root" user is still the owner of all system files, and several OS tools will be confused if the user root with uid 0 no longer exists. And while we've removed uid 0 checks from our kernel modules, some may persist in external device drivers; although we've gone to considerable lengths to remove uid 0 checks from programs, a few still survive. Of course, such uid 0 checks are futile in that the uid may be 0, yet the process may not be privileged anyway. So, the short answer to your question is "no"; we will want to make this possible in a future release and certainly for Trusted Solaris. Q: Can I use privileges to remove assumed access from a login? I'm specifically thinking about making it so that a login/role has no write access to any files, regardless of what ACLs or standard permissions may already allow. Is this something at the VFS level so that any file system (SAMFS/QFS, tmpfs, UFS, ZFS, vxfs, etc.) will honor, or does the file system need to specifically support this? (If so, which file systems would support this?) Finally, how would I enable this? A: In the Solaris 10 OS we introduce the notion of "basic" privileges; this is a set of privileges which every user's process gets on initial login but which can be taken away by specifying a different set in the user's user_attr entry. The "basic" set is defined such that we can move currently unprivileged operations into it and everything will continue to work as before. To properly support basic privileges, you should not empty a privilege set except to the basic set and then subtract those privileges you know you do not need. The current basic set is as follows: $ ppriv -lv basic file_link_any Allows a process to create hardlinks to files owned by a uid different from the process' effective uid. proc_exec Allows a process to call execve(). proc_fork Allows a process to call fork1()/forkall()/vfork(). proc_info Allows a process to examine the status of processes other than those it can send signals to. Processes that cannot be examined cannot be seen in /proc and appear not to exist. proc_session Allows a process to send signals or trace processes outside its session. And if you want to remove the "proc_info" privilege from a user's login, you'd specify that user's privileges as "defaultpriv=basic,!proc_info" (start from basic and then subtract) in /etc/user_attr. At this point there's no "basic privilege" which allows us to remove all write access from files; it is one of those things on my "to do" list. If we implemented such a thing, it would likely be at the VFS or syscall layer. Other privileges are implemented in the file systems themselves; we created a number of routines to support file system writers in converting the file systems to privileges. So there is a way to give users less access than they had on older Solaris releases but not to the point that you want. But it's certainly an interesting feature to have, and that's why we're considering adding it. Q: Sometimes we need to install PowerBroker to allow certain users to have some root privileged access for their daily work. They use the following: $ pbrun some_command
Do we have something in the Solaris 10 OS to process rights natively? A: The Solaris 8 OS and later versions have RBAC, which offers very much the same functionality. See, for example, the rbac(5) and pfexec(1) manual pages. Q: In an answer given to another question in this session, you said "quite a few programs and processes have been modified to take advantage of fine-grained privileges. For example, traditionally set-uid programs like ufsdump, ufsrestore, rsh, rlogin, rdist, rcp, ping, traceroute, w and uptime now run with just the privileges they need." On b72 I see that ufsdump, ping, and traceroute are all suid root. So what has changed? Do they drop all privileges other than the required ones, as soon as possible? Could you give more details? A: Currently, "set-uid root" is unfortunately still the only way to be blessed with additional privileges. The programs generally needed uid 0 for a limited number of things, reserved ports in the case of ufs*, r* and icmp, or raw sockets for ping and traceroute. In the Solaris 10 OS, these processes reduce uid 0 immediately to the required privilege level at start. Q: Do you plan to provide a "priv" attribute in exec_attr(4), besides the currently supported ones (uid, euid, gid, egid)? This would allow a profile to execute a command with certain privileges. A: There already is one. exec_attr defines both "privs" (privileges added when a program is run) and "limitprivs" (upperbound on privileges). Q: Is there a GUI tool included with the Solaris 10 OS for Process Rights Management? A: I believe that SMC includes this for user administration. Q: Are the errors descriptive enough as to whether they are because of PRM or -- let's say -- RBAC problems? A: We hope so (there are many levels of tracing). Q: Will they have any effect in diagnosing logging facilities like BSM or lastcomm commands? A: Lastcomm no, but BSM includes privileges used. |
 | |||||
 | |
