Messages in this thread | | | Subject | Re: [RFC] [PATCH] file posix capabilities | From | Stephen Smalley <> | Date | Wed, 16 Aug 2006 09:20:01 -0400 |
| |
On Tue, 2006-08-15 at 21:42 -0500, Serge E. Hallyn wrote: > Quoting Stephen Smalley (sds@tycho.nsa.gov): > > On Tue, 2006-08-15 at 06:49 -0500, Serge E. Hallyn wrote: > > > Quoting Nicholas Miell (nmiell@comcast.net): > > > > 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 majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |