Bug#883948: apparmor: xdg-user-dirs should have localized directory names

[Vincas Dargis]

Package: apparmor
Version: 2.11.1-4
Severity: wishlist

Dear Maintainer,

Currently `tunables/xdg-user-dirs` has only english versions of common
user directories:

```
@{XDG_DESKTOP_DIR}="Desktop"
@{XDG_DOWNLOAD_DIR}="Downloads"
@{XDG_TEMPLATES_DIR}="Templates"
...
```

This means that abstractions like `user-download`, `user-write` and similar
woudn't help on non-english desktop systems.

Maybe it would be possible to collect all translations available? Or
that would load profile too mutch?

Or, maybe some sort of hook could be implemented, or task-x-desktop be
used in any way to deploy an include file with appropriate translations?

-- System Information:
Debian Release: buster/sid
APT prefers unstable
APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 4.14.0-1-amd64 (SMP w/8 CPU cores)
Locale: LANG=lt_LT.UTF-8, LC_CTYPE=lt_LT.UTF-8 (charmap=UTF-8), LANGUAGE=lt_LT.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages apparmor depends on:
ii debconf [debconf-2.0] 1.5.65
ii libc6 2.25-3
ii lsb-base 9.20170808
ii python3 3.6.3-2

apparmor recommends no packages.

Versions of packages apparmor suggests:
ii apparmor-profiles 2.11.1-4
ii apparmor-profiles-extra 1.16
ii apparmor-utils 2.11.1-4

-- Configuration Files:
/etc/apparmor/parser.conf changed [not included]

-- debconf information excluded

[intrigeri]

Hi,

good catch! It would be interesting to know how other distros
handle this.

Cheers,

[Vincas Dargis]

Post by intrigeri
Hi,
good catch! It would be interesting to know how other distros
handle this.

I already have Ubuntu and OpenSuse VM's (in addition to Debian), I could check that I guess.

[Vincas Dargis]

Tried OpenSUSE Tumbleweed, and no, localized Downloads folder was not allowed when using `abstractions/user-download`.

[Vincas Dargis]

Ubuntu does not handle handle localized directories too:

```
***@vincas-ubuntu1804:~$ foo ~/Atsiuntimai/fake.download
foo: /home/vincas/Atsiuntimai/fake.download: Permission denied
***@vincas-ubuntu1804:~$ cat /etc/apparmor.d/usr.local.bin.foo
#include <tunables/global>

@{foo_executable} = /usr/local/bin/foo

profile @{foo_executable} {
#include <abstractions/base>
#include <abstractions/user-download>

@{foo_executable} r,
}
```

Where `foo` is simply a copy of `/bin/cat`.

It works after I add:

`@{XDG_DOWNLOAD_DIR}+=Atsiuntimai`

into

`/etc/apparmor.d/tunables/xdg-user-dirs.d/site.local`.

as expected.

[Vincas Dargis]

I've started discussion in debian-i18n list, asking for guidance:
https://lists.debian.org/debian-i18n/2019/01/msg00000.html

[intrigeri]

Control: severity -1 minor
Control: tag -1 + upstream
Control: forcemerge -1 918548

Rationale for the metadata changes:

- This bug is about a given proposed solution to a broad class
of problems.

- Bumping severity to minor, as the lack of a solution to this
problem may lead to writing policy that's more relaxed than it
could be, so let's call this >> wishlist (I'm curious about
practical examples though: in practice, users expect to be allowed
to read & save files wherever DAC allows them to; I doubt there's
actual profiles in Debian that we would dare make stricter by
default, even once this problem is solved). Not more than minor,
for reasons explained there: https://bugs.debian.org/918548#25

- Tagging "upstream", as a designing a good solution requires
cross-distro discussion to get the interfaces right; and I would be
a good solution will have an upstream component.

All in all, I'm not convinced the cost/benefit of making the
@{XDG_*_DIR} tunables translatable is particularly interesting.
One can't expect users to write their documents in XDG_DOCUMENTS_DIR,
nor to store their music in XDG_MUSIC_DIR: doing so is certainly
convenient when using a modern full-blown desktop environment, but
(thankfully!) humans are much more creative than that.

So I'd personally rather zoom out a bit and consider the more general
problem of "it's hard to predict at policy writing time where the user
will want to read/write files from/to". For some part of this problem
(when explicit user interaction is needed anyway), well known
solutions exist, for example the security by designation design
pattern, as implemented in Portals. For other parts of this problem,
e.g. "my music player should be allowed to read all my music files",
other solutions are needed; but I don't think that translating the
@{XDG_*_DIR} AppArmor tunables is one of them (too bad, because as
Jamie said, that seems pretty doable).

I've intentionally postponed this problem during the Buster cycle, as
a way to make "AppArmor enabled by default in Debian" tractable.
This has lead to making some of our policy super relaxed, and to
disabling some profiles by default. But I plan to tackle some of them
post-Buster, some of it in AppArmor upstream, some of it in Debian,
and probably some of it in other relevant upstreams.