[apparmor] FatRat profile
Seth Arnold
seth.arnold at canonical.com
Tue Mar 19 17:31:25 UTC 2013
On Tue, Mar 19, 2013 at 07:13:01PM +0400, "Артём Н." wrote:
> Profile for the FatRat download manager.
> I didn't test it carefully, but it works.
Nice. I've got a few comments inline..
> -----
> #
> # FatRat apparmor profile.
> #
>
> # vim:syntax=apparmor
>
> # Last Modified: Sun Feb 17 10:43:47 2013
> # Author: Artiom N. <artiom14 at yandex.ru>
>
> #include <tunables/global>
>
> /usr/bin/fatrat {
> #include <abstractions/base>
> #include <abstractions/nameservice>
> #include <abstractions/fonts>
> #include <abstractions/freedesktop.org>
> #include <abstractions/kde>
> #include <abstractions/gnome>
> #include <abstractions/user-download>
>
> # Not needed.
> # #include <abstractions/ubuntu-bittorrent-clients>
It would probably be better to just remove lines that aren't needed.
It's one thing to leave them in while making changing changes to someone
else's profiles and discussing them.
> # Paranoia.
> #include <abstractions/private-files-strict>
>
> /usr/bin/fatrat mr,
>
> /usr/bin/xdg-open rmix,
> /usr/lib/fatrat/** rmk,
> /usr/share/fatrat/** rmk,
> /usr/share/kde*/** rm,
> /usr/share/lintian/overrides/fatrat-data r,
>
> owner @{PROC}/*/ r,
> # owner @{PROC}/net/dev r,
> # root, root
> @{PROC}/*/net/dev r,
Same here, I'd think remove both commented lines
> /home/ r,
> owner @{HOME}/.config/Dolezel/fatrat.conf rwk,
Is 'Dolezel' unique to your configuration? Or common for the
application?
> owner @{HOME}/.kde/share/config/kdebugrc r,
> owner @{HOME}/.kde/share/config/kdeglobals rk,
> owner @{HOME}/.kde/share/icons/** rk,
> owner @{HOME}/.local/share/fatrat/ rwk,
> owner @{HOME}/.local/share/fatrat/** rwmk,
>
> # Optional.
> deny @{HOME}/Desktop/ rwmkl,
> deny @{HOME}/Desktop/** rwmkl,
>
> }
> -----
>
> Also I've added @{TORRENT_CLIENT} in tunables/global and I've granted
> permissions on execution it in browser's rules.
>
> tunables/global:
> @{TORRENT_CLIENT}=/usr/bin/fatrat
This is going to lead to trouble. What we have now is admittedly
complex, but it is designed to avoid the user editing tunables/global
directly -- once the user modifies the file, it'll be prompted about for
upgrades for ever.
That's why the current approach includes the other files, which users
are encouraged to modify -- it'll be easier for them to accept/deny
changes on upgrades in the future, or preseed settings at installation
time.
> abstractions/ubuntu-browsers.d/other (file, included in browser's profiles):
> @{TORRENT_CLIENT} rPx,
This doesn't really play nicely with the existing
ubuntu-bittorrent-clients portion of policy, which gives torrent clients
the sanitized_helper near-unconfined-status. (Not that near-unconfined
torrent clients are a good idea; just a pragmatic idea. :)
It'd be nice to have an easier way to migrate torrent clients to confined
from the sanitized_helper over time. I'm not sure what the variables
_ought_ to look like to help...
Thanks
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 490 bytes
Desc: Digital signature
URL: <https://lists.ubuntu.com/archives/apparmor/attachments/20130319/76560202/attachment.pgp>
More information about the AppArmor
mailing list