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/
This archive was generated by hypermail 2b29 : Tue Feb 15 2000 - 21:00:18 EST