Cc: Dr. David Alan Gilbert <linux@...>, Crispin Cowan <crispin@...>, Arjan van de Ven <arjan@...>, Linux Kernel Mailing List <linux-kernel@...>, LSM ML <linux-security-module@...>, apparmor-dev <apparmor-dev@...>
the mechanism being desired was that the system administrator would setup
a restrictive policy and a user who wanted a more permissive policy would
have the ability to make it more permissive.
this sort of thing is a disaster waiting to happen.
however, if App Armor sets things up so that there can be a system policy
that users cannot touch, but users can have a secondary policy that layers
over the system one to restrict things further it could be safe.
if a sysadmin wants to have 'soft' and 'hard' limits of what a user can
do, they could put the 'hard' limits in the system policy (and the users
_cannot_ violate these limits), and then set the 'soft' limits in the
users default setup (similar to how .profile is set by default). if a user
wants to make things less restrictive they could edit or remove the
per-user policy, but would still not be able to violate the system policy.
however, while this seems attractive, I'm not sure that madness isn't down
the road a little bit. since the users policy would only apply to
themselves, you have the situation that (DAC permissions permitting) the
files are available to other confined processes becouse they are running
as other users. this sort of thing will surprise people if the
explinations aren't done very carefully.
David Lang
-
