Re: Filesystem Capabilities in 2.6?

[Linus Torvalds]

On Sat, 2 Nov 2002, Oliver Xymoron wrote:
> 
> Bindings are cool, but once you start talking about doing a lot of
> them, they're rather ungainly due to not actually being persisted on
> the filesystem, no? 

Well, they _are_ persistent in the filesystem, although in this case "the 
filesystem" is /etc/fstab.

It's not that different from the ".capabilities" file, except it's a lot 
more explicit, and from an implementation standpoint it's a lot easier.

However, I think there is a problem with Al's original approach: the bind 
can _not_ be just a mask that takes away capabilities from a suid 
application, since that would imply that the app has to be marked suid in 
the first place (and accessing it _without_ going through the bind will 
give it elevated privileges, which is what we're trying to avoid).

So the bind would have to _add_ capabilities, not take them away.

That's not really a problem, and the advantage of the filesystem bind
approach is that it is extremely explicit, and it is trivial for a
maintainer to at all times see all such "elevated" binaries: as Al points
out, the only thing you need to do is to just ask to be shown the mount
list with "mount" or with "cat /proc/mounts".

> A better approach is to just make a user-space capabilities-wrapper
> that's setuid, drops capabilities quickly and safely and calls the
> real app.

This is _not_ a good approach from a sysadmin standpoint. The sysadmin
does not explicitly know what the suid binary does internally, the
sysadmin just sees a number of suid binaries and has to trust them.

Yes, I realize that your example had "showcapwrap" etc sysadmin tools to 
work around this, and make the wrapping be transparent to the sysadmin. 
That certainly works, although it still depends on trusting that the 
wrapping cannot be confused some way. I guess that could be done fairly 
easily (although I think you'd want to make "mkcapwrap" actually _sign_ 
the wrapped binaries, to make sure that nobody can later try to inject a 
"bad" binary that _looks_ ok to "showcapwrap" and fools the admin to think 
everything is ok).

But from a security maintenance standpoint, wouldn't it be _nice_ to be 
able to

 - do a complete "find" over the whole system to show that there is not a 
   single suid binary anywhere.

 - trivially show each and every binary that is allowed elevated 
   permissions (and _which_ elevated permissions) by just doing a "mount".

 - and since the mount trees are really per-process, you can allow certain 
   process groups to have mounts that others don't have.

I think that as a anal-retentive security admin, I'd like such a system.

		Linus