[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4738EB67.40304@manicmethod.com>
Date: Mon, 12 Nov 2007 19:10:15 -0500
From: Joshua Brindle <method@...icmethod.com>
To: casey@...aufler-ca.com
CC: Crispin Cowan <crispin@...spincowan.com>,
"Dr. David Alan Gilbert" <linux@...blig.org>,
Arjan van de Ven <arjan@...radead.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
LSM ML <linux-security-module@...r.kernel.org>,
apparmor-dev <apparmor-dev@...ge.novell.com>
Subject: Re: AppArmor Security Goal
Casey Schaufler wrote:
> --- Crispin Cowan <crispin@...spincowan.com> wrote:
>
>
>> Dr. David Alan Gilbert wrote:
>> ...
>>
>> Can you explain why you want a non-privileged user to be able to edit
>> policy? I would like to better understand the problem here.
>>
>> Note that John Johansen is also interested in allowing non-privileged
>> users to manipulate AppArmor policy, but his view was to only allow a
>> non-privileged user to further tighten the profile on a program. To me,
>> that adds complexity with not much value, but if lots of users want it,
>> then I'm wrong :)
>>
>
> Now this is getting interesting. It looks to me as if you've implemented
> a mandatory access control scheme that some people would like to be able
> to use as a discretionary access control scheme. This is creepy after
> seeing the MCS implementation in SELinux, which is also a DAC scheme
> wacked out of a MAC scheme. Very interesting indeed.
>
This is the same sort of thing we are trying to do in SELinux with the
policy management server
<http://oss.tresys.com/projects/policy-server/wiki/PolicyServerDesign>,
ofcourse the policy management server enforces SELinux policy on what
can be changed and what can't. We devised a scheme to allow the policy
to become more restrictive without being able to change the policy
'intent' using a type hierarchy.
In fact I was talking to a coworker today about how this could be done
with smack, using the same kind of hierarchy and allowing unprivileged
users (eg., those without MAC_OVERRIDE) to create new smack labels
'under' their own which would be restricted. This is interesting because
of the ability to create new smack domains on the fly but since only
privileged users can do it it is of limited use. Imagine if a user could
create a new domain for their webbrowser or anything else they care to.
Since they can't add rules to the policy it would effectively just be a
user sandbox, an interesting use indeed.
-
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