[apparmor] [patch 20/21] Add the ability to specify ptrace rules

[John Johansen]

On 03/21/2014 06:34 PM, Seth Arnold wrote:
> On Mon, Mar 17, 2014 at 04:29:30PM -0700, john.johansen at canonical.com wrote:
>> ptrace rules currently take the form of
>>
>>   ptrace [<ptrace_perms>] [<peer_profile_name>],
>>   ptrace_perm := read|trace|readby|tracedby
>>   ptrace_perms := ptrace_perm | '(' ptrace_perm+ ')'
>>
>> After having used the cross check (permission needed in both profiles)
>> I am not sure it is correct for ptrace.
> 
> Hrm, I'm liked the idea of the cross-check here for some time, but haven't
> actually lived with it yet. What doesn't work so well?
> 
>> @@ -470,6 +471,15 @@
>>  <DBUS_MODE,SIGNAL_MODE>{
>>  	send		{ RETURN_TOKEN(TOK_SEND); }
>>  	receive		{ RETURN_TOKEN(TOK_RECEIVE); }
>> +}
>> +
>> +<PTRACE_MODE>{
>> +	trace		{ RETURN_TOKEN(TOK_TRACE); }
>> +	viewedby	{ RETURN_TOKEN(TOK_READBY); }
>> +	tracedby	{ RETURN_TOKEN(TOK_TRACEDBY); }
>> +}
>> +
>> +<DBUS_MODE,SIGNAL_MODE,PTRACE_MODE>{
> 
> 'viewedby' feels out of place; there's also no 'read' nor 'readby' here
> but I'm not sure that matters?
> 
heh yeah sorry I must have missed refreshing that. Notice the TOK_READBY

>>  	read		{ RETURN_TOKEN(TOK_READ); }
>>  	write		{ RETURN_TOKEN(TOK_WRITE); }
>>  	{OPEN_PAREN}	{
>> @@ -481,9 +491,11 @@
>>  			}
>>  }
>>  
>> -<MOUNT_MODE,DBUS_MODE,SIGNAL_MODE>{
>> +<MOUNT_MODE>{
>>  	{ARROW}		{ RETURN_TOKEN(TOK_ARROW); }
>> +}
> 
> Was this intentional?
> 
hrmm, yes no. Its from some messing I did play with the syntax (so deliberate)
but uhm got dropped and I missed it here (so not deliberate)

>> +rules:  rules opt_prefix ptrace_rule
>> +	{
>> +		if ($2.owner)
>> +			yyerror(_("owner prefix not allowed on ptrace rules"));
> 
> And again the question about 'owner', it isn't exactly redundant with
> capability sys_ptrace, it still might be useful for root processes.
> 
Again to do with permission encoding. It will come