Re: Linux Security *Module* Framework (Was: LSM conversion to static interface)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Jan Engelhardt wrote:
I disagree.

Traditionally, Linux has given a process all capabilities when the
UID changed to 0 (either by setuid(2) or executing a SUID binary).
This has been relieved over the years, and right now with LSMs in the
field, it is possible to 'deactivate' this special case for UID 0.
SELinux does not have this special case for UID 0. Neither does it
seem to use capabilities (quick grep through the source). So
basically, all users are the same, and no one has capabilities by
default. Does SELinux thus break with other LSMs?

Now assume a SELinux system where all users have all capabilities
(and the policy that is in place restricts the use of these
capabilities then) -- should not be that unlikely. Does that break
with other LSMs?
MultiAdmin loaded before Selinux breaks Selinux since Multi Admin rules are applied over using Selinux rules. This is just the way it is stacking LSM's is Just not healthy you always risk on LSM breaking another. Part of the reason why I have suggested a complete redesign of LSM. To get away from this problem of stacking.

I see MultiAdmin purely in the class of posix file capabilities( Fine grained replacement to SUID). This is a standard feature fix not part of LSM. Note it can not replace all SUID bits due to some internals of applications design need to be changed to support posix file capabilities in particular not checking if running as UID 0. Traditional UID 0 is already optional for applications without LSM's.

Posix file capabilities only applies to applications only. MultiAdmin being the user mirror of Posix file capabilities.

MultiAdmin patch to the user side may allow more SUID bits to be killed off from the start line. So increasing overall system security.

Of course MultiAdmin might end up two halfs. One a standard feature that hands out capabilities to users that LSMs can overrule. And one a user by user directory access control LSM directory control LSM less likely to cause problems.

I really don't see the need for a LSM stacking order. Some features just should not be LSM's in my eyes. MultiAdmin is one of them.

Traditional way has all ready been expanded for applications without LSM's. So my call still stand O heck head ache rating. Because its in the wrong place. Particularly when you think people will want to use it stacked with other LSM's. Stacking should be avoided where able. This means at least some of Multiadmin features just have to be done core kernel as a normal kernel module to avoid stacking and breaking the LSM.

Note posix file capabilities was developed as a LSM module too at first the point came where it was going to cause more trouble for other LSMs granting stuff in conflict. Both Multiadmin and posix file capabilities share a lot in common. Both developed in the wrong place. Both required to be else where. Even there function is similar breaking down root powers and handing them out more effectively. So in my eyes it is a pure Posix extension not a LSM.

Peter Dolding
-
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/

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]
  Powered by Linux