[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