Re: [RFC] [PATCH] file posix capabilities

[Serge E. Hallyn]

Quoting Stephen Smalley (sds@xxxxxxxxxxxxx):
> On Tue, 2006-08-15 at 06:49 -0500, Serge E. Hallyn wrote:
> > Quoting Nicholas Miell (nmiell@xxxxxxxxxxx):
> > > 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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/