[pkg-apparmor] Bug#918548: Bug#918548: About possibility to translate AppArmor tunables

Vincas Dargis vindrg at gmail.com
Mon Jan 7 17:12:14 GMT 2019


On 2019-01-07 13:30, Ian Jackson wrote:
> Vincas, thanks for reporting this bug on the debian-i18n list.
> I think it needs a much higher profile.

We already have AppArmor bug [0].

Intention of debian-i18n is to figure is it possible to "automate" translation upon 
AppArmor/language installation.

>> The problem is that on my machine, "Desktop" is actually "Darbastalis",
> 
> I think you mean "in your account" ?  I mean, if you had several users
> who used different languages, wouldn't their "Desktop" directory be
> called different things ?

I do not know when these XDG dirs are "translated". If I choose Lithuanian language upon Debian 
desktop installation, I get Lithuanian "Darbastalis". So I assume it's default based on "system 
language", if that's ever a thing?

I do see that KDE settings allows user can select completely different "Desktop" directory. That 
would be kinda out of scope, as that would need some sort of AppArmor helper and kernel variables to 
change these "on the fly". This is "over my head", so we should ask AppArmor developers to comment 
this...

My intent is to somehow translate "official" Desktop "names".

> 
>> ```
>> @{XDG_DESKTOP_DIR}+="Darbastalis" #lt
>> @{XDG_DESKTOP_DIR}+="Darbvirsma" #lv
>> @{XDG_DOWNLOAD_DIR}+="Atsisiuntimai" #lt
>> @{XDG_DOWNLOAD_DIR}+="Lejupielādes" #lv
>> ...
>> ```
> 
> These are interesting ideas.  I don't know enough to say if they would
> work.

Yes, appending variable "value list" works, I've been testing by modifying 
`/etc/apparmor.d/tunables/xdg-user-dirs.d/site.local` file:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=883948#25

My idea was maybe it is possible to "translate on the installation", based on *available* languages 
in the system, instead of pre-translating "Desktops" into all known languages and ship (by upstream 
itself) a big fat `/etc/apparmor.d/tunables/xdg-user-dirs` file. Not sure what would be performance 
hit by having such a variables containing all known "Desktops" and "Downloads, etc, for AppArmor 
kernel module to perform matching.


>> Though I am not sure how that could be achieved, hence I ask this
>> list for guidance.
> 
> I think this requires some technical input from the AppArmor folks.
> I see you CC'd the uploader already but I think this is a bug and
> should be tracked in the Debian BTS.

Again, [0].


> I have set the bug to `serious' because of this impact as described by
> Vincas:
> 
>> if AppArmor profile for application "Foo" defines rule
>> `@{XDG_DESKTOP_DIR}/** r,` to allow reading from desktop, it will
>> not work for my localized desktop directory name.
> 
> That is phrased hypothetically but I imagine it is common.  That kind
> of thing is after all what these rules are there fore.

The reality is that profiles that ship in distributions are rather.. permissive, like, allowing to 
access all $HOME (except sensitive dot files & directories of course) in order not to break user 
experience too much. For example, from Thunderbird's profile [1]:

```
   # rw access to HOME is useful when sending/receiving attachments
   owner @{HOME}/[^.]** rw,
```

Or LibreOffice [2]:

```
@{libo_user_dirs} = @{HOME} /mnt /media

...

owner @{libo_user_dirs}/**.@{libreoffice_ext} rwk,  #Open files rw with the right exts
```

Or Totem [3]:
```
   # Allow read and write on almost anything in @{HOME}. Lenient, but
   # private-files-strict is in effect.
   #include <abstractions/private-files-strict>
   owner @{HOME}/[^.]*    rw,

```

Of course, it would be nice if GUI application would only allow (let's say) Downloads and Desktop to 
be accessible by default, and allow strict-full (no dot files & dirs) if users choose so, by 
enabling "less permissive mode" *somewhere* (by some GUI configurator, etc), but that would needs 
AppArmor tooling, "helpers", etc...

Well, there is `aa-update-browser` utility (in apparmor-utils) that can be used in Ubuntu (as it 
ships Firefox profile, although disabled by default) to select how strict AA policy of Firefox is. 
If there would be similar tooling to configure (in user-friendly way, not by fiddling with AA 
profiles) arbitrary application profile, then these XDG_XYZ_DIR's would be much more helpful.

> To the AppArmor maintainers:
> 
> I have filed this as `serious' not to try to force you to fix this,
> but because this bug seems like it will cause AppArmor to work badly
> for many people and I felt you would want me to be sure you noticed.
> So please adjust the severity as you like.

Since these variables are note really looks "interesting" in current AppArmor state, I doubt this 
bug should be marked as "serious". More like a feature request to be useful in the future.

[0] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=883948
[1] 
https://gitlab.com/apparmor/apparmor-profiles/blob/c69719d970a5ae96835b01b165ca19a1b2da2c42/ubuntu/19.04/usr.bin.thunderbird#L80
[2] 
https://cgit.freedesktop.org/libreoffice/core/tree/sysui/desktop/apparmor/program.soffice.bin?id=3272c1eb5563f3bda2caa24f32b1018372622109#n103
[3] 
https://gitlab.com/apparmor/apparmor-profiles/blob/c69719d970a5ae96835b01b165ca19a1b2da2c42/ubuntu/19.04/usr.bin.totem#L36



More information about the pkg-apparmor-team mailing list