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
| ||
|
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/
Powered by blists - more mailing lists