lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite for Android: free password hash cracker in your pocket
[<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

Powered by Openwall GNU/*/Linux Powered by OpenVZ