Scope and Using devices

Robert Wittams robert at wittams.com
Tue Jun 1 15:29:23 PDT 2004


Robert Love wrote:

> On Tue, 2004-06-01 at 13:26 -0400, Joe Shaw wrote:
> 
>> The core problem of access control still exists, but really that problem
>> exists no matter what.  If we want to do setting, we can probably either
>> implement our own (I've done it for Red Carpet, so I'm starting to get
>> good at it. ;) or reuse dbus's.  But I'd rather see it fixed somehow in
>> the operating system, maybe using POSIX capabilities.  But I hope that
>> Robert will be able to answer more to that than I could. :)
> 
> I agree that the access control should be solved at the correct level -
> e.g. the kernel - and not elsewhere, either.
> 
> POSIX capabilities would be pretty nice.  They multiplex the current
> root/non-root nightmare onto one of many per-task rights, such as
> CAP_SYS_NICE and CAP_NET_ADMIN.
> 
> Problem is, capabilities need filesystem support - in place of the 1-bit
> setuid flag, we need an (3*m)-bit capabilities mask for m capabilities.
> I think I heard once that the estimate is 100-bits per file.
> 
> Not a big deal, but it is not in the kernel.  I think people have worked
> on it in the past, but no one is currently working on it - the patches
> are not up to date.
> 
> Plus, user-space tools are spotty and documentation is thin.  Current
> system administrators have trouble with the current 12 permission bits
> that UNIX defines.  Who knows what field day they will have with
> managing all of the capabilities on a per-file basis.
> 
> Which leads us to what Joe and I have hacked on this morning ...
> 
> Apps can run as setuid root, drop all capabilities but the requested one
> (s), and then set their uid's to the running (or any arbitrary) user.
> This can be done as the very first lines of code in the program,
> providing effectively the same results as if the filesystem supported
> capabilities.
> 
> Joe and I have some test code that does the above.  It works.
> 
> This leaves the onus of solving the access control problem on the core
> OS, where it belongs.
> 
> Robert Love

I thought POSIX caps were broken: 
http://lwn.net/Articles/84566/

Quoting Andrew Morton : "Capabilities are broken and don't work". 

Or is this out of context / only applies to some situations? 

The whole dropping caps thing has always seemed pretty bad ( having scads of
setuid root programs linked to such bastions of security as Qt, Gtk and
embedded python interpreters just seems somehow risky). 

Is there any reason why these priveleged operations can not be controlled by
normal file access permissions to files in a virtual filesystem? I've never
understood why this couldn't / shouldn't be done - eg for binding to ports
under 1024, etc etc. Of course, this entails kernel changes, so its maybe
not for the short term. 

Rob


_______________________________________________
hal mailing list
hal at freedesktop.org
http://freedesktop.org/mailman/listinfo/hal



More information about the Hal mailing list