Re: [RFC] [PATCH] file posix capabilities

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/

Relevant Pages

  • Re: [RFC] [PATCH] file posix capabilities
    ... models on to TE/RBAC-based security models, ... is already well underway for SELinux, but you would have to replicate it ... you would need to consider whether the capability module needs to ... many operations only involve uid comparisons and SELinux ...
    (Linux-Kernel)
  • Re: [PATCH -v3 1/3] Capabilities: move cap_file_mmap to commoncap.c
    ... security_file_mmap ifndef CONFIG_SECURITY like all of the other capability ... denied by selinux or by caps..... ... subject to a further restrictive check by other security modules. ... I don't see any reason why that shouldn't be capable. ...
    (Linux-Kernel)
  • Re: [PATCH -v3 1/3] Capabilities: move cap_file_mmap to commoncap.c
    ... security_file_mmap ifndef CONFIG_SECURITY like all of the other capability ... Personally, not really, but I'll gladly put them back if you care. ... denied by selinux or by caps..... ... I don't see any reason why that shouldn't be capable. ...
    (Linux-Kernel)
  • Re: + smack-version-11c-simplified-mandatory-access-control-kernel.patch
    ... Smack - other MAC modules like SELinux won't honor it. ... But what about the MAC modules like Smack that do honor it? ... They shouldn't be using a module specific capability, ... restrictive model of the LSM. ...
    (Linux-Kernel)
  • Re: [PATCH -v3 1/3] Capabilities: move cap_file_mmap to commoncap.c
    ... security_file_mmap ifndef CONFIG_SECURITY like all of the other capability ... denied by selinux or by caps..... ... Most of commoncap.c is called either as a secondary hook from the active ... does not define that LSM hook, so it just defaults to the cap_* hook. ...
    (Linux-Kernel)