--- Joshua Brindle <[EMAIL PROTECTED]> wrote: > Casey Schaufler wrote: > > --- Crispin Cowan <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-security-module" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html