Messages in this thread | | | From | (Peter Benie) | Subject | Re: Capabilities | Date | Thu, 10 Feb 2000 23:29:56 +0000 |
| |
In article <Pine.LNX.4.21.0002101833050.20618-100000@ferret.lmh.ox.ac.uk>, Chris Evans <chris@ferret.lmh.ox.ac.uk> wrote: >On Thu, 10 Feb 2000, Matthew Kirkwood wrote: > > [Peter Benie wrote:] > > > 1) Permitted capability set for setuid programs > > > > > > I want setuid root programs not to have all capabilites. cap_bound is > > > not the answer since I still want some programs that are started from > > > the system initialisation scripts to run with all capabilities. > > > > Mmm.. I'd like that too. > > You'll get that when the filesystem support for capabilities goes in.
Filesystems without capabilities will exist for a _long_ time, and people will want to be able to use them for setuid root programs. How about diskless clients mounting their root filesystem over NFS?
> Alternatively, tighten up the bounding set as part of your system > initialisation scripts.
As Matthew points out, that doesn't work since it affects all processes, not just setuid processes.
I haven't really figured out what the bounding set is for. It doesn't seem to do anything that couldn't be done trivially by using wrappers in inittab to remove capabilities from the inheritable set a la Irix.
And I'm puzzled by the capabilities given to init. Why doesn't init run with all capabilites? cap_setpcap is a subset of cap_sys_admin (because of mknod and /dev/kmem) so I see no point in not making setpcap inheritable from init.
> > > 2) Inherited capability set for setuid programs > > > > > > It is possible to run a non-capability-aware setuid-root program from > > > an environment that has cap_setuid-i. This prevents the program from > > > using setuid() to demote privilege back to a non-zero uid (unless that > > > uid was the real, effective or saved uid). This is a security risk > > > > The whole lot, or merely CAP_SETUID?
The whole lot, so we get the old behaviour for setuid root back.
> > I see no reason that these two shouldn't be sysctls. Want > > a patch? > > It feels like functionality for the sake of it.
The behaviour of the inheritable capabilities when doing setuid emulation changes the assumptions that setuid programs are allowed to make - setuid root programs are expected to be capability aware.
This makes me very nervous since it is impossible to analyse what the possible consequences of this are without reading the source to every setuid root program. I would be much happier if setuid emulation accurately implemented the traditional behaviour of setuid root since that brings us back to the status quo. It may not be ideal, but it doesn't introduce any extra problems.
I haven't come up with an example of an exploit involving the inheritable capabilities, but I can say where I would start looking. Choose a program that uses more than two uids as part of its operation (ie. your uid, 0, and something else). Queuing systems are good candidates. I'll pick exim (an MTA). Run it with cap_setgid+i and cap_setuid-i. (IME, programs check the return value from initgroups but don't check for setuid; exim is no exception.) Now check in /proc which uids exim is running with. Oops - it's running as root when it shouldn't be.
> Once we've got some proper, extensive _real world_ use of capabilities, > we'll be in a better situation to evaluate what tweaks/additions are > required. Quite a lot of capabilities complaints boil down to > "theoretically, this could be an issue" rather than "I've been using > capabilities to do X, and came across this issue"
Solving the theoretical problems makes the design secure. Solving the practical problems make the design usable.
It is in the nature of security holes that code is pushed beyond the limits of what the author expected. Assuming that certain input data will never happen is likely to lead to security holes, therefore you should consider problems that you consider merely 'theoretical'. Only looking at practical problems will tell you a lot about the API, but will tell you little about how secure the design is.
Peter
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |