[apparmor] [RFC] handling XDG user directories
Christian Boltz
apparmor at cboltz.de
Sat Aug 10 20:46:03 UTC 2013
Hello,
your proposal looks very good.
Nevertheless, let me add some notes (as usual ;-)
Am Dienstag, 6. August 2013 schrieb John Johansen:
> On 08/05/2013 03:59 PM, Jamie Strandboge wrote:
> > and users/admins can adjust /etc/apparmor.d/tunables/xdg-dirs or
> > drop files into /etc/apparmor.d/tunables/xdg-dirs.d, providing a
> > welcome convenience[2].
> I know that people like the drop in dir bits, but quite bluntly I
> don't, for most things, its a way of papering over real problems (of
> course I consider treating profiles the way we do with packaging as a
> problems so ...)
Tell us a better way ;-)
> > This of course doesn't solve everything. Because users can modify
> > theirrs ~/.config/user-dirs.dirs file at will and have it point
> > anywhere, so we can't examine those files and do anything automatic
> > there (when we have user policy we can revisit this). This proposal
> > handles translations well though and use of
> This depends on what you are trying to enforce. If its a system level
> policy that is anything but advisory we can't ever let the user
> control the location.
Exactly - otherwise things will become funny when a user sets
XDG_DOWNLOAD_DIR="/" (wow, my browser can write everywhere! :-)
If we allow the user config to be read, then it needs some restrictions:
- only inside @{HOME} (and no "../" allowed) (even if I can guarantee
you that users will complain about this ;-)
- there must be a config option to disable reading ~/.config/, maybe
we should even disable it by default
> If its a system level policy enforcing an advisory location for the
> user circumsribed by some larger control eg.
> @{HOME/** intersected with user defined @{HOME}/@{XDG_DESKTOP_DIR}
yes, something like that - and also at least
#include <abstractions/private-files> # or ...-strict
> If you mean that a user can set their translations sure, but again
> that doesn't currently reflect what system policy does. The sys admin
> can choose the set of local translations that are acceptable to
> system policy
good point, see below
> > * apparmor-xdg-dirs.py: this takes the output of 'locale -a' and
I'm afraid this will result in a bit too much ;-)
On my system, locale -a gives me 270 locales from aa_DJ to zu_ZA
(and I even dropped suffixes like @euro or .utf-8 - with them, I get 460
locales) [1]
In other words: this should be configurable:
a) autogenerate for all installed languages (which would be a lot on my
system)
b) autogenerate for all languages in $config_option
c) similar to b), but somehow automated (on openSUSE, you can choose to
install for example "all german translations" in YaST - this should
also add the german XDG dirs to apparmor)
d) do not autogenerate anything
Option a) might even result in too many permissions - I'm quite sure in
one of the 270 locales I have, for example ~/downloads translates to a
directory name I have, and that should not be accessible ;-)
The perfect solution would be to only allow the directory names in each
user's language (so the profile would have /home/cb/Dokumente/ and
/home/english/documents/ for example) - but I know that's not really
easy to implement ;-)
Regards,
Christian Boltz
[1] I have no idea why this happens, the only thing I can imagine is
that openSUSE has some *-lang packages that contains all non-english
texts, and locale -a picks up all of the languages from them.
--
> [...] is currently down due to a failure in the NAS system.
> [...]
> your NAS (network attached storage)
Oh. I thought it stood for Networked Adrian Schröter :D
[> Adrian Schröter and Jean Delvare in opensuse-buildservice]
More information about the AppArmor
mailing list