Re: LSM conversion to static interface

From: Giacomo A. Catenazzi
Date: Tue Oct 23 2007 - 05:14:51 EST

Jan Engelhardt wrote:
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.

Nothing wrong. I only said that it was against (IIRC) the
principle of LSM in kernel (we should only remove capacities).
I've nothing against the changing the design or rules.
It was only a commentary, to be sure that we know what we do ;-)

ciao
cate
-
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/