Hello Daniel, On Tue, Jan 19, 2016 at 09:35:33PM +0100, daniel curtis wrote: > Firstly, I would like to ask about 'requested_mask' and 'denied_mask' with > 'rwc' value. What is the right access rule (in AppArmor profile) that is > responsible for 'rwc' action? How such rule should look like? 'r' stands > for (read), 'w' stands for (write) and what 'c' means? Create?
Correct, the 'c' means 'create' -- there's no direct permissions for this
in the AppArmor user-facing language, but the infrastructure exists if we
want to expose it in the future. The user-friendly tools convert the 'c'
to 'w' permission.
> Secondly, transmission-gtk is trying to access the encrypted data in
> '$HOME/.ecryptfs/user/.Private'. Some important configuration information
> are stored in $HOME/.ecryptfs, right? 'requested' and 'denied_mask' is "w"
> (write). Should I allow transmission-gtk to access this directory/location?
> If yes, is this a sufficient rule?:
>
> >> maybe it should be restricted with 'owner'?
> /home/.ecryptfs/user/.Private/ rw,
Unfortunately I don't think we have any alternatives to this. 'owner' is
probably a good idea if you have multiple users on the system that may run
transmission-gtk. You may also need 'k' permissions at some point. The
whole point of the encrypted names is to make them impossible to predict
or otherwise correlate with the unencrypted names, so you really can't do
better than this.
> There is one more thing: name="/proc/sys/kernel/random/uuid". Requested and
> denied mask is "r" (read). What about this one? Can I allow
> transmission-gtk to read uuid? If yes, is this an okay rule?:
>
> @{PROC}/sys/kernel/random/uuid r,
Yeah, this is fine, this is just a simple wrapper around the kernel's
randomness functions with the correct uuid output format.
Thanks
signature.asc
Description: Digital signature
-- AppArmor mailing list AppArmor@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/apparmor
