Quoting Jan Engelhardt ([EMAIL PROTECTED]): > > On Oct 23 2007 07:44, Giacomo Catenazzi wrote: > > > >> 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.
Once the per-process capability bounding set is accepted (http://lkml.org/lkml/2007/10/3/315) you will be able to do something like: 1. Create user 'jdoe' with uid 0 2. write a pam module which, when jdoe logs in, takes CAP_NET_ADMIN out of his capability bounding set 3. Now jdoe can log in with the kind of capabilities subset you describe. It's not a perfect solution, since it doesn't allow jdoe any way at all to directly execute a file with more caps (setuid and file capabilities are subject to the capbound). So there is certainly still a place for multiadm. -serge - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
