Re: [RFC][PATCH] Thoughts about capabilities and prototype patch for user-capabilities

[Chris Wright]

* Alexander Nyberg (alexn@xxxxxxxxx) wrote:
> I recently had an idea of having something similar
> to /etc/user_capabilites which would consist of
> username:CAP_CHOWN,CAP_SOMETHING,CAP_SOMETHING2

pam_cap should do this (alas due to brokeness of current scheme it
doesn't).

> This could very well be loaded into linux at the time of an application
> doing sys_setuid, sys_setreuid and the likes by hooking into glibc. The
> kernel also requires a small patch which I'll inline below for comments.
> I sure would use some of these capabilities on my user. And they could
> be used to solve things like a certain program/user needs to use
> real-time scheduling (just something like CAP_SCHED allowing arbitray
> scheduling or CAP_MEMLOCK allowing a user to lock memory. This would
> solve some of the old problems).

ITYM CAP_IPC_LOCK and CAP_SYS_NICE.  The ability to mlock is already
controlled by an rlimit, so the capability is not needed except as an
override.  As for scheduling, this is being actively worked on.  I have
a patch to make scheduling controlled by rlimits as well, and Ingo and
Con are working on scheduler modifications that may allow low-latency
for normal unprivilged users.

> I haven't looked into making capability bits for certain files, mostly
> cause I don't know vfs much and also I don't see this colliding with it,
> I think both should exist. 

This work has been done a few times, but never got much traction mainly
due to the complexity of managing such a scheme.

> I don't know what the plans are for capabilities in the future but there
> are quite some shortcomings in the current implementation. I think it at
> least should allow to set/get capabilites of process ids, user ids and

Olaf Dietsche posted a patch recently that allows you to do this as well,
you might look at that.  It's a bit different approach, but all of these
are working around the fact that it's simply broken right now.

> group ids. These are the things that come to my mind directly. I also
> see that 28 of the 32 currently possible slots are taken which will be a
> problem if capabilities are ever gonna get serious.

Actually we just added two more.  Yes we're against the edge.  FreeBSD
went straight to 64 bits.  That's probably the easiest transistion.
Of course, there's also the problem that some capabilities are so broad
as to be meaningless for privilege separation.

> While looking at it today I noticed user-space over here doesn't even
> seem to have macros/functions to set/test/clear bits in the blackboxed
> types which means anyone want to use it will be exposed to the raw
> structure.

Check libcap, there's quite a few functions for handling that.

> So I'm curious of what the thoughts are for capabilities, are they gonna
> go away some day in the future? I hope not, I think the idea is simple
> and good but something needs to be done about the implementation to
> allow it to be of full use. And yes, I volunteer, but I'm not all sure
> about which direction has been discussed and where this is going.

The biggest thing to fix right now is the fact that you can't allow
capabilities to be inherited as they should be.  This is what makes them
of very limited use.

> Below you will find a test program and at the bottom a patch which allows
> a priviledged user to set the capabilities of another user (i386 only). 
> Setting capabilities on groups does not work, it requires some more code
> (I don't think much though).

This is potentially quite risky.  In fact, the underlying ability is
there already (in capset), but the required privilege has been removed
(CAP_SETPCAP).  As for the syscalls, don't think we want to add them or
this type of functionality now.  We're better off fixing what we have
instead of adding more features.

thanks,
-chris
-- 
Linux Security Modules     http://lsm.immunix.org     http://lsm.bkbits.net
-
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/