[apparmor] [RFC] handling XDG user directories

Tue Aug 6 18:45:55 UTC 2013

On 08/05/2013 03:59 PM, Jamie Strandboge wrote:
> = Background =
> 
> The xdg-user-dirs specification[1] allows for translatable and movable common
> directories. While this may be beneficial for users who for example want to have
> ~/Pictures translated into their own language, this flexibility provides
> challenges for AppArmor. Untranslated xdg user directories are typically (see
> ~/.config/user-dirs.dirs):
> XDG_DESKTOP_DIR="$HOME/Desktop"
> XDG_DOWNLOAD_DIR="$HOME/Downloads"
> XDG_TEMPLATES_DIR="$HOME/Templates"
> XDG_PUBLICSHARE_DIR="$HOME/Public"
> XDG_DOCUMENTS_DIR="$HOME/Documents"
> XDG_MUSIC_DIR="$HOME/Music"
> XDG_PICTURES_DIR="$HOME/Pictures"
> XDG_VIDEOS_DIR="$HOME/Videos"
> 
> On an Ubuntu system with the fr_CA locale installed, these become:
> XDG_DESKTOP_DIR="$HOME/Desktop"
> XDG_DOWNLOAD_DIR="$HOME/Téléchargements"
> XDG_TEMPLATES_DIR="$HOME/Templates"
> XDG_PUBLICSHARE_DIR="$HOME/Public"
> XDG_DOCUMENTS_DIR="$HOME/Documents"
> XDG_MUSIC_DIR="$HOME/Musique"
> XDG_PICTURES_DIR="$HOME/Images"
> XDG_VIDEOS_DIR="$HOME/Vidéos"
> 
> While the kernel and AppArmor parser handle these translations fine, the
> profiles do not. I think we can do better and make this a bit easier for
> distributions.
>
I'd like to see how we could make it worse, that would be a feat ;)

> = Proposal =
> 
> As an upstream, we can vastly improve the situation by simply creating the
> xdg-dirs tunable using the default 'C' xdg-user-dirs values:
> $ cat /etc/apparmor.d/tunables/xdg-dirs
> @{XDG_DESKTOP_DIR}=Desktop
> @{XDG_DOWNLOAD_DIR}=Downloads
> @{XDG_TEMPLATES_DIR}=Templates
> @{XDG_PUBLICSHARE_DIR}=Public
> @{XDG_DOCUMENTS_DIR}=Documents
> @{XDG_MUSIC_DIR}=Music
> @{XDG_PICTURES_DIR}=Pictures
> @{XDG_VIDEOS_DIR}=Videos
> 
> # Also, include files in tunables/home.d for site-specific adjustments to
> # the various XDG directories
> #include <tunables/xdg-dirs.d>
> 
> and then create the /etc/apparmor.d/tunables/xdg-dirs.d directory. With that
> alone, we can start using rules like this in our upstream policy:
> 
>   owner @{HOME}/@{XDG_MUSIC_DIR}/** r,
> 
makes sense

> 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].
> 
hrmmm, this [2] is not good, the @{HOME} variable in the expression
  @{XDG_DESKTOP_DIR}=@{HOME}/Desktop

should have expanded, this is a bug we need to look into to.

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 ...)

> 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.

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}

or what ever restriction the system policy author chooses to place on a user accessing
their own files, then sure we can auto generate with the understanding that the
user can change these locations to other files they can access, again making it
advisory only

of course advisory that requires the user log out so policy gets reloaded or some
such may stop evil app

As for user defined policy, it makes a lot of sense to auto generate

> translations for these directories happens outside of the user's control. Users
> who modify ~/.config/user-dirs.dirs can update policy like they need to now.
> 
err how? I thought the point was to stop the user from being able to directly
modify policy.

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

> I have written two tools that we may want to optionally ship[3]:
of course we will want to ship them at least short term

Longer term I am not sure we don't want to have the parser generate a set of
translations at load time instead of having an external app do it. This would
require a control file for the set of translations to use but would have the
advantages of
- keeping policy based translations up to date, without additional packaging
  hooks
- would provide the base for user policy to dynamically adjust to users changing
  their ~/.config/user-dirs.dirs

>  * apparmor-xdg-dirs-simple.py: this takes a locale as an argument and outputs
>    to stdout something suitable for dropping into /etc/apparmor.d/xdg-dirs.d.
>    Eg:
>    $ ./apparmor-xdg-dirs-simple.py zh_HK
>    @{XDG_DESKTOP_DIR}+="Desktop"
>    @{XDG_DOWNLOAD_DIR}+="下載"
>    @{XDG_TEMPLATES_DIR}+="Templates"
>    @{XDG_PUBLICSHARE_DIR}+="Public"
>    @{XDG_DOCUMENTS_DIR}+="文件"
>    @{XDG_MUSIC_DIR}+="音樂"
>    @{XDG_PICTURES_DIR}+="圖片"
>    @{XDG_VIDEOS_DIR}+="影片"
> 
>    A very simplistic usage could be:
>    # ./apparmor-xdg-dirs-simple.py zh_HK > /etc/apparmor.d/xdg-dirs.d/zh_HK
> 
>  * apparmor-xdg-dirs.py: this takes the output of 'locale -a' and outputs to
>    stdout something suitable for dropping into /etc/apparmor.d/xdg-dirs.d as
>    well, but tries to be a little smarter and only outputs unique translations,
>    skipping the 'C' locale (since the C locale dirs are presumed to already be
>    in /etc/apparmor.d/tunables/xdg-dirs). Eg, on an Ubuntu 13.10 system with
>    the en, fr and zn locales installed:
>    $ ./apparmor-xdg-dirs.py
>    # This file contains translations for XDG directories based on
>    # the installed locales from the local system. To regenerate,
>    # redirect the output of 'apparmor-xdg-dirs' to this file.
>    @{XDG_DOWNLOAD_DIR}+="Téléchargements"
>    @{XDG_DOWNLOAD_DIR}+="下載"
>    @{XDG_DOCUMENTS_DIR}+="文件"
>    @{XDG_MUSIC_DIR}+="Musique"
>    @{XDG_MUSIC_DIR}+="音樂"
>    @{XDG_PICTURES_DIR}+="Images"
>    @{XDG_PICTURES_DIR}+="圖片"
>    @{XDG_VIDEOS_DIR}+="Vidéos"
>    @{XDG_VIDEOS_DIR}+="影片"
> 
>    A possible usage in a distribution might be:
>    # ./apparmor-xdg-dirs.py > /etc/apparmor.d/xdg-dirs.d/system
> 
> I was quite happy in testing when I saw that the kernel and parser (both v3)
> handled these utf-8 strings just fine such that with this rule:
> 
:)

>   owner @{HOME}/@{XDG_MUSIC_DIR}/** r,
> 
> I was able to write to:
>  ~/Musique/testme
>  ~/音樂/testme
>  ~/Music/testme
> 
> but not to, for example:
>  ~/圖片/testme
> 
> Logging worked well too:
> Aug  5 15:09:05 sec-saucy-amd64 kernel: [ 7115.061670] type=1400
> audit(1375733345.046:74): apparmor="DENIED" operation="mknod" parent=10586
> profile="test-xdg" name=2F686F6D652F6A616D69652FE59C96E789872F746573746D65
> pid=16114 comm="touch" requested_mask="c" denied_mask="c" fsuid=1000 ouid=1000
> 
> $ aa-decode 2F686F6D652F6A616D69652FE59C96E789872F746573746D65
> Decoded: /home/jamie/圖片/testme
> 
\o/

> I did not test other tools (aa-logprof, etc) for these utf-8 strings, but any
oh please don't, I don't want to go there

> problems there would be just bugs (and my proposal doesn't actually add utf-8
> strings).
> 
well it might be more than that as those strings are subject to python and perls
string handling

> What do people think? Maybe this would be a good topic for this month's meeting.
> 
sure, but I think I count to acks already

> Thanks!
> 
> PS - note that this (intentionally) doesn't cover the XDG base-dir
> specification, though we could solve it in the same manner. Create an
> /etc/apaprmor.d/tunables/xdg-basedir tunable with standard values, then create
> the /etc/apparmor.d/tunables/xdg-basedir.d directory that people can use if they
> want. I don't think we would provide any more tools beyond to avoid crossing an
> privilege boundaries and mucking around in $HOME.
> 
yeah, this one will require some careful thought/implementation to ensure we
aren't shooting ourselves in the foot

> 
> [1] http://freedesktop.org/wiki/Software/xdg-user-dirs/
> [2] Note, I initially tried to do this:
>     $ cat /etc/apparmor.d/tunables/xdg-dirs
>     @{XDG_DESKTOP_DIR}=@{HOME}/Desktop
> 
>     but this didn't work. The parser liked it just fine, but the '@{HOME}'
>     wasn't expanded. I don't think this is a problem and think I prefer
>     the current proposal, but mention it for completeness.
> [3] lp:~jdstrand/+junk/apparmor-xdg
> [4]http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html
> 
> 
> 