Date: Wed, 24 Jun 1998 23:05:25 -0400 From: "Allen Smith" <easmith@beatrice.rutgers.edu> To: dg@root.com, tqbf@pobox.com Cc: njs3@doc.ic.ac.uk, dima@best.net, security@FreeBSD.ORG, abc@ralph.ml.org, tqbf@secnet.com, easmith@beatrice.rutgers.edu Subject: Re: bsd securelevel patch question Message-ID: <9806242305.ZM4253@beatrice.rutgers.edu> In-Reply-To: David Greenman <dg@root.com> "Re: bsd securelevel patch question" (Jun 24, 11:47am) References: <199806241847.LAA01163@implode.root.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Jun 24, 11:47am, David Greenman (possibly) wrote: > >This solution has very real security benefits, but I find administrating > >them from login.conf to be clumsy. In terms of transitioning away from > >binary "superuser" privilege, I think normal Unix filesystem security > >semantics (owner, group, and SET[UG]ID) are expressive enough. > > I don't think this scales very well. Assigning specific gids as > privileges is also rather messy inside the kernel and makes > probably wrong assumptions about a machine's external /etc/group > layout. One could mitigate this a bit by exporting the assignment > of these via individual sysctl() variables. As it happens, that's how I've done it - via a quad sysctl variable - although that has the admitted problem that, given how quad variables work in gcc, it's difficult to specify a constant for them, so no redefining via the config file except in a rather crude way (on/off - off being a value below 0 or above the maximum for gid_t (currently a u_int32_t). OTOH, given that various files will need to be installed set to a particular gid (e.g., ping), having this be very variable (no pun intended) between installations would cause problems in any event. (Admittedly, I haven't looked yet at how to handle the on/off mechanism with file installation - at first it'd need to be manual.) > I also think the issue of handling setuid/setgid binaries is > independant of a fine grained privilege mechanism. Even in your > scheme, if I understand it completely, you'd only be able to have > one capability enabled via setgid, so you'd be out of luck if you > needed two since you can't specify a list of groups. This is a general problem with the current implementation of setuid/gid files and multiple groups, yes. What is needed is a way for some setuid binaries to be initialized with the group set of the uid they're set to. This will also cure some existing problems with the setuid/gid system, among which are: A. you can't have a setgid program with execution of it limited to a particular group. (If you're writing the program, this is no problem... but if it's one you're porting in, this can be a problem - see below.) Various schemes with wrappers are admittedly possible but clunky. B. files that should be accessible to a limited group of programs can't have a subset of those programs also being able to access some other group-limited group of files. In other words, I'm suggesting the solution to the problem is to fix this - not to set up a new system, orthogontal to this, that is fixed already. The mechanism of doing so necessitates that setuid programs be able - preferably selectively - to access the set of group permissions that the user they're setuid to would normally have. In order to do this, the kernel needs to know the groups associated with each uid. I would suggest loading them in with a system call usable only by process 1, similarly to securelevel downward setting - init would do this on startup and on a HUP, as per rereading the /etc/ttys file - to protect those of us (like me once another Seagate SCSI drive gets installed) with an /etc/group file on a read-only filesystem. There is then the problem of telling which setuid files should have their group list initialized. The best way to tell this would appear to be the currently unused sticky bit (unused for executables, at least). When a setuid file with the sticky bit was executed: A. kern_exec would check for the new uid's listing in the data set created by the above system call B. if the uid was found, the groups would be initialized to the groups of the new uid, except that the 0th gid would be left unchanged unless the executable was also setgid; the 1st gid would, as usual, contain the 'password gid' of the new uid C. a flag would be set in the process in question indicating that this had been done Whenever another process was executed by a process with the flag set, so long as that process was not setuid with the sticky bit set: A. the groups list, other than the 0th gid (left the same as before), would be reinitialized to that of the real uid (possibly unless the result was the same group list, in which case the saved uid would be used instead) B. the flag would be unset Whenever the uid or euid of a process with the flag set was changed: A. the groups list, other than the 0th gid (left the same as before), would be reinitialized to that of the new uid B. if the real, effective, and saved uids were all the same, the flag would be unset > I agree that setuid root has always been an inadequate sledgehammer > for granting access to privileged resources and capabilities. I think the > best way to handle this, however, is with a file ACL mechanism that allows > for the specification of privileges as and extension of the access control > information. On the other hand, in VMS, special privileges can be granted to > a binary only if it is "installed" first - i.e. made known to the system as > a special executable, usually at system startup time. This has the advantage > of specifying all binaries that have elevated privilege(s) in one place and > keeping privileged binaries open (making media changes difficult or > impossible), but has the disadvantage of violating POLA. This has definite possibilities, but I'd point out the problem of porting. This is accentuated by that the most critical system binaries are the ones which would be given privileges (currently setuid root), and these are ones that you want to be able to quickly fix security holes in - which is not helped if it's hard to port in an improved version, patches, etcetera from another system. Typically, various binaries are already set up to gain and relinquish privileges at particular points; having those privileges be independent from the mechanism they're expecting to use (uids and groups) is going to open up potential security holes. In either case, I'd be willing to help with programming on this this summer, although my speed of doing so will be slow - I'm not a very good C programmer, and have other things to do (I'm a graduate student, and _not_ in computer programming). I really don't want to do so and see my work go to waste by a different method being decided on, however. -Allen P.S. Here's a brief list of the sort of groups/privileges I'm thinking about: 1. Ability to do ICMP, with limitations (no spoofing, no multicast/broadcast, limited or no socket option setting); partially implemented (as in coded (except for some stuff regarding socket options) but not fully debugged). Useful for ping, pinger, etcetera. Admitted potential vulnerabilities are mostly DOS (as is already the case with ping), but redirect messages concern me. 2. Ability to send/receive from a _particular_ UDP port below 1024. Useful for ntpd, etcetera. 3. Ability to accept connections to, but not connect out from, a _particular_ TCP port below 1024. Useful for http, anonymous ftp, etcetera. The 'accept connections to' is to prevent spoofing of rsh, ssh in some modes, etcetera. 4. Ability to set the time, perhaps with limits in setting it back via means other than adjtime and similar drift (non-jump) programs. Again, useful for ntpd, etcetera. 5. Ability to set that process's own priority, including to real-time IO values. Again, useful for ntpd, etcetera. I'm perfectly willing to work on others, but these are the ones that I can most justify putting my time into, given my responsibilities here. If somebody can suggest other ones of use in running a firewall machine (with squid, ntpd, etcetera as proxys, essentially), I'd be interested in working on those. -- Allen Smith easmith@beatrice.rutgers.edu To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?9806242305.ZM4253>