[apparmor] FatRat profile

["Артём Н."]

19.03.2013 21:31, Seth Arnold пишет:
> 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
Ok. At your discretion.

>>   /home/                                      r,
>>   owner @{HOME}/.config/Dolezel/fatrat.conf   rwk,
> Is 'Dolezel' unique to your configuration? Or common for the
> application?
I think, it not depends on the configuration:
http://fatrat.dolezel.info/
:-)

> 
>>   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.
Yes, I understand, that inclusion <abstractions/ubuntu-bittorrent-clients> is
more flexible, than setting variable.
But, I think this is a really complex and give more rights, than a program needs.
Am I wrong?

>> 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. :) 
But I haven't found fatrat in ubuntu-bittorrent-clients and I didn't like
sanitized_helper. :-)
Why does torrent client need to run programs in /sbin or /usr/bin?
Why is it not a good idea to make helper with more restrictions?

> It'd be nice to have an easier way to migrate torrent clients to confined
> from the sanitized_helper over time
Which is the way?

> I'm not sure what the variables
> _ought_ to look like to help...
Yes, of course, if user[s] have many programs for one purpose...