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 :)
> proper assignment and management of the capability bits on files, and
> teaching userland that uid 0 is no longer magic.
Of course setuid still works, so it doesn't need to be done all at once.
> Which is all work that
> is already well underway for SELinux, but you would have to replicate it
> for capabilities. And since there is no notion of equivalence classes
> ala SELinux types and the "policy" is completely distributed throughout
> the filesystem state, management is going to be even more painful for
> the capabilities.
But since file capabilities cannot survive an exec, analysis with a gui
which walks the fs could be pretty simple.
> 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.
Thanks.
-serge
-
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]
