[apparmor] PATCH: apparmor.d man page

[John Johansen]

On 06/07/2016 03:47 PM, Seth Arnold wrote:
> On Tue, Jun 07, 2016 at 01:46:46PM -0700, John Johansen wrote:
>> Add documentation of the profile flags and how to debug apparmor policy to the apparmor.d man page
> 
> This is great, thanks!
> 
> Acked-by: Seth Arnold <seth.arnold at canonical.com>
> for all three branches.
> 
replying to a few specific comments/questions the rest have been incorporated
into v2 in some way

> "user of the keyword" -> "use of the keyword" --- I'm surprised it's worth
> adding the "enforce" mode flag at all.
> 
it mostly about symmetry. There have been a few who have tried and it didn't
work.

Much like adding the allow keyword provided symmetry and fixed the same
issue of people trying and failing.

>> +=item B<kill> -- conflicts with allow, complain, enforce, stop
>> +Instead of logging denials, send a kill signal to the task. Note there
>> +are some accesses where a task is not associated, in those cases no
>> +kill signal will be sent.
>> +
>> +Not yet supported in versions before AppArmor 4.0
>> +
>> +=item B<stop> -- conflicts with allow, complain, enforce, kill
>> +A debug mode where a SIGSTOP or SIGSYS may be sent to the task for unknown
>> +accesses. Note there are some accesses where a task is not associated, in
>> +those case a signal will not be sent.
>> +
>> +Not yet supported in versions before AppArmor 4.0
> 
> Maybe it'd be easier to list which combinations of modes are valid, and
> what they accomplish.
> 
yep as Christian asked for

>> +
>> +The proper solution is almost always to uses delegation or disconnected
>> +path rules. If this option is used the disconnect_root should be set to a
>> +value other than the default of "/".
> 
> This would be a nice place to show an example, once it works. :)
> 

sure

>> +
>> +=item B<no_attach_disconnected> DEFAULT -- conflicts with attach_disconnected
>> +
>> +Disconnected paths are not attached, or mediated via file pathname rules.
> 
> "not attached or mediated" -- how does this work with e.g.:
> 
> profile p {
>   change_profile ** -> q,
> }
> 

this will be denied. If the path lookup is disconnected

> profile q { ... }
> 
> If a filedescriptor to bin/sh is available to a process executing in p
> will the change on exec happen? How about if it's written:
> 
>   change_profile -> q, ? or
>   change_profile * -> q, ?

the fd revalidation will fail so access to the fd will be denied. In older
versions of apparmor at the read hook, in newer the fd will be duped to
the special null in the inherit hook.

So an open fd that is disconnected will not cause an exec to fail.

Now if the exec is the disconnected path, the exec will fail.




-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <https://lists.ubuntu.com/archives/apparmor/attachments/20160609/adfc10b2/attachment.pgp>