[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4727C06A.4060005@gmail.com>
Date: Wed, 31 Oct 2007 09:38:18 +1000
From: Peter Dolding <oiaohm@...il.com>
To: linux-kernel@...r.kernel.org, linux-security-module@...r.kernel.org
Subject: Re: Linux Security *Module* Framework (Was: LSM conversion to static
interface)
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 majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists