On Oct 23 2007 07:44, Giacomo Catenazzi wrote:
quoted text
>
>> I do have a pseudo LSM called "multiadm" at 
>> http://freshmeat.net/p/multiadm/ , quoting:
>
>> Policy is dead simple since it is based on UIDs. The UID ranges can be 
>> set on module load time or during runtime (sysfs params). This LSM is 
>> basically grants extra rights unlike most other LSMs[1], which is why 
>> modprobe makes much more sense here. (It also does not have to do any 
>> security labelling that would require it to be loaded at boot time 
>> already.)
>
>But his is against LSM design (and first agreements about LSM):
>LSM can deny rights, but it should not give extra permissions
>or bypass standard unix permissions.

It is just not feasible to add ACLs to all million files in /home,
also because ACLs are limited to around 25 entries.
And it is obvious I do not want <prof> to have UID 0, because
then you cannot distinguish who created what file.
So the requirement to the task is to have unique UIDs.
The next logical step would be to give capabilities to those UIDs.

*Is that wrong*? Who says that only UID 0 is allowed to have
all 31 capability bits turned on, and that all non-UID 0 users
need to have all 31 capability bits turned off?

So, we give caps to the subadmins (which is IMHO a natural task),
and then, as per LSM design (wonder where that is written) deny
some of the rights that the capabilities raised for subadmins grant,
because that is obviously too much.
-
unsubscribe notice
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/