On Tue, 2006-08-15 at 21:42 -0500, Serge E. Hallyn wrote:
> Quoting Stephen Smalley ([email protected]):
> > On Tue, 2006-08-15 at 06:49 -0500, Serge E. Hallyn wrote:
> > > Quoting Nicholas Miell ([email protected]):
> > > > OTOH, everybody seems to have moved from capability-based security
> > > > models on to TE/RBAC-based security models, so maybe this isn't worth
> > > > the effort?
> > >
> > > One day perhaps, but that day isn't here yet. People are still using
> > > setuid (see /sbin/passwd), so obviously they're not sufficiently
> > > comfortable using *only* TE/RBAC.
> >
> > The hard part of capabilities isn't the kernel mechanism - it is the
>
> I didn't claim to be doing the hard part :)
Yes, but the question is whether anyone will do the hard part. And
whether it is worth doing. And whether you make the system unsafe along
the way, particularly given the permissive nature of capabilities.
> But since file capabilities cannot survive an exec, analysis with a gui
> which walks the fs could be pretty simple.
Except that people actually want them to be inheritable (under certain
conditions), just in a way that avoids the problems encountered in the
past. If you start on the path of making capabilities useful, you'll
have to tackle that as well.
> > On the kernel side, in addition to updating the bprm_secureexec logic,
> > you would need to consider whether the capability module needs to
> > implement capability comparisons for the other hooks, like task_kill.
> > At present, many operations only involve uid comparisons and SELinux
> > checks without explicitly comparing capability sets. Properly isolating
> > and protecting processes with different capability sets but the same uid
> > is something SELinux already can do (based on domain), whereas the
> > existing capability module doesn't really provide that.
>
> Very good point. Preventing communication channels i.e. through signals
> isn't a concern, but user hallyn ptracing himself running /bin/passwd
> certainly is.
Actually, ptrace already performs a capability comparison (cap_ptrace).
Wrt signals, it wasn't the communication channel that concerned me but
the ability to interfere with the operation of a process running in the
same uid but different capabilities, like stopping it at a critical
point. Likewise with many other task hooks - you wouldn't want to be
able to depress the priority of a process running with greater
capabilities.
One other point to consider is Solaris seems to have diverged from their
own past approaches for privileges/capabilities,
http://blogs.sun.com/casper/20040722
http://www.opensolaris.org/os/community/security/library/howto/privbracket/
Doesn't sound like they are even using file capabilities at all.
Also, think about the real benefits of capabilities, at least as defined
in Linux. The coarse granularity and the lack of any per-object support
is a fairly significant deficiency there that is much better handled via
TE. At least some of the Linux capabilities lend themselves to easy
privilege escalation to gaining other capabilities or effectively
bypassing them.
--
Stephen Smalley
National Security Agency
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
