[apparmor] [PATCH 03/10] From a3f0ccf618c2016ce5fbaa0fe35d4f194fbefd2b Mon Sep 17 00:00:00 2001 From: John Johansen <john.johansen at canonical.com> Date: Sat, 27 Oct 2012 04:49:23 -0700 Subject: [PATCH 03/10] add optional allow prefix to the language

[John Johansen]

On 07/25/2013 11:37 AM, Christian Boltz wrote:
> Hello,
> 
> Am Sonntag, 21. Juli 2013 schrieb John Johansen:
>> -- /dev/null
>> +++ b/parser/tst/simple_tests/capability/ok_allow2.sd
>> @@ -0,0 +1,160 @@
>> +#
>> +#=DESCRIPTION validate some uses of capabilties.
>> +#=EXRESULT PASS
>> +# vim:syntax=subdomain
> 
> What about syntax=apparmor ? ;-)
> 
>> +# Last Modified: Sun Apr 17 19:44:44 2005
>> +#
>> +/does/not/exist {
>> +  audit allow capability chown,
>> +  audit allow capability dac_override,
> 
> I somehow remember the parser enforced alphabetic order of keywords. Is 
> this still valid? (If yes, it should be "allow audit".)
> 
nope it was never alphabetic order (though it may look that way), its
always been

[audit] [deny] <rule>

the intention being

[audit ctl] [rule perm modifier] <rule>


so eventually the plan has been to enable several things at the rule
level so that you can have a profile that is learning but is still denied
access to certain things.

[audit|quite] [allow|deny|complain|prompt|stop|kill] <rule>

deny - out right deny permission request
complain - audit request but allow
prompt - prompt user for input on what should be done. This is more of
         an extension for userspace helpers and won't be supported on
         kernel rules, at least not initially
stop - a debugging mode, that will send the task a signal to cause it
       to stop when it makes a certain permission request.
kill - like deny but kill the task