linux-kernel - Re: AppArmor Security Goal

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: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <916293.58775.qm@web36601.mail.mud.yahoo.com>
Date:	Mon, 12 Nov 2007 20:58:23 -0800 (PST)
From:	Casey Schaufler <casey@...aufler-ca.com>
To:	Joshua Brindle <method@...icmethod.com>, 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


--- Joshua Brindle <method@...icmethod.com> wrote:

> 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.

It would be easy to add a label "owner" the same way that there's
an optional CIPSO mapping now. Writes to /smack/load would require
that the writer be the owner of the object label in the rule. I think
it would still require privilege to assign ownership, a non-parsed
write to /smack/labelowner should suffice for the mechanism. It seems
that you might need to support multiple labels for this to be really
effective, but I'm not sure why I think that. I'm also not sure that
once you draw a complete picture it won't be indistinguishable from
POSIX ACLs.


Casey Schaufler
casey@...aufler-ca.com
-
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/