| 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: Sat, 10 Nov 2007 15:52:31 -0800 (PST) From: david@...g.hm To: "Dr. David Alan Gilbert" <linux@...blig.org> cc: Crispin Cowan <crispin@...spincowan.com>, 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 On Sat, 10 Nov 2007, 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. > > I think it might depend on how strict the users starting point is; > you could say: > 1 This document editor can read and write any part of the users home > directory other than the . files. > > or you could say: > 2 This document editor can read any files but only write to the > 'Documents directory'. > > If the adminisrator set something up with (2) as the starting point it > would seem reasonable for the user to be able to add the ability to edit > documents in extra directories for their style of organising documents > they work on; but they would be restricted in what they could add > so that they couldn't add the ability to write to their settings > files. but how can the system know if the directory the user wants to add is reasonable or not? what if the user says they want to store their documents in /etc? > <snip> > >>>> AppArmor will let you do that; most of the work is in splitting the >>>> application. If you can get e.g. Firefox to use a separate process that >>>> it exec's for editing your preferences, then AppArmor can confine that >>>> helper app with a different policy than Firefox itself, including >>>> granting the helper write permission to the config directory. >>>> >>> Yes, and designing the app so that it's filenames are predictable; >>> firefox has a fun habit of using randomly named profile directories. >>> >> You just glob that directory, so the rule would look like: >> >> /home/*/.mozilla/default/*/prefs.js rw, >> >> if you wanted it to be a generic policy for all users. If you want a >> tighter policy for your workstation, then it might look like >> >> /home/dagilbert/.mozilla/default/somemozillarandomstring/prefs.js rw, >> >> hard-coding both your username and the random directory name that >> Mozilla chose. a question for Crispin, is there a wildcard replacement for username? so that you could grant permission to /home/$user/.mozilla...... and grant each user access to only their own stuff? I realize that in this particular example the underlying DAC will handle it, but I can see other cases where people may want to have users more intermixed (say webserver files or directories for example) > Allowing a user to tweak (under constraints) their settings might allow > them to do something like create two mozilla profiles which are isolated > from each other, so that the profile they use for general web surfing > is isolated from the one they use for online banking. the model of being able to add restrictions would still handle this. make two shell scripts (one to start each browser profile) and set the AA policy for these scripts to only have access to the appropriate directories. David Lang - 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