[apparmor] [profile] transmission-gtk, the encrypted data and requested/denied 'rwc'.

[daniel curtis]

Hello.

Yes Jamie, You're right: 'uuid' is root owned and there is a denied entry
with 'fsuid=1000, ouid=0' in a log file (e.g. '/var/log/syslog'). So, I
will try to remove 'owner' and see what happens. But it is not more secure
with the 'owner' option?

Seth, You wrote that "the 'owner' modifier on this rule is preventing the
read", right? Also the DENIED line on my system is similar to your.
Requested and denied mask ("r") and 'fsuid=1000 ouid=0'. Yes, I noticed
that 'fsuid' and 'ouid' are different.

Okay, now the 'k' access mode and ~/Private directory. If I need to grant
privileges I would like to ask if these rules are okay?:

>> log file contain: requested_mask="rw" denied_mask="rw"
owner /home/.ecryptfs/my_user/.Private/    rw,
owner /home/.ecryptfs/my_user/.Private/*    rw,

What about a second rule? Transmission is trying to access ("rw")
'~/.Private/ECRYPTFS_FNEK_ENCRYPTED.FWY....' so should I use just one '*'
or it is better to use '**'? I'm sorry for a such naive question but it is
pretty important location etc.

Summing up; after all changes transmission-gtk profile should have:

--- owner @{PROC}/sys/kernel/random/uuid    r,
+++ @{PROC}/sys/kernel/random/uuid    r,

--- owner /home/.ecryptfs/my_user/.Private/    rwk,
+++ owner /home/.ecryptfs/my_user/.Private/    rw,
+++ owner /home/.ecryptfs/my_user/.Private/*    rw,

What do You think about this? Is this correct? One more thing: after adding
"#include <local/usr.bin.transmission-gtk>" at the end of the profile,
during AppArmor restart (e.g. via '/etc/init.d/apparmor restart' command)
there is a parser error saying: "Could not open
'local/usr.bin.transmission-gtk'". Should I create transmission-gtk file in
'/etc/apparmor.d/local/ directory, leave it empty or it is not needed at
all?

Thank You for the answers, best regards.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/apparmor/attachments/20160122/72f1e3da/attachment.html>