[apparmor] [patch 15/12] v3 unix socket rules

[John Johansen]

On 08/31/2014 07:52 PM, Jamie Strandboge wrote:
> On 08/31/2014 04:06 PM, Jamie Strandboge wrote:
>> On 08/30/2014 09:19 PM, John Johansen wrote:
>>> fix output of listen and setopts commands
>>>
>>> The listen and setopts commands have broken encodings because the
>>> tmp stream they use to handle diverging from the other commands
>>> has does not set its write position to to the end of the copied data.
>>> Instead the write head is set to the beginning so that when the
>>> new data for the command is written it overwrites the begging of
>>> the command instead of appending to it.
>>>
>> So, before this patch, I was seeing denials like this:
>>   apparmor="DENIED" operation="setsockopt" profile="/usr/sbin/cupsd" pid=4283
>>   comm="cupsd" family="unix" sock_type="stream" protocol=0
>>   requested_mask="setopt" denied_mask="setopt" peer_name=none
>>
>> Yet none of this policy would make the denial go away:
>>   unix (setopt) type=stream peer=(addr=none),
>>   unix (setopt) type=stream,
>>   unix (setopt),
>>
>> Does this patch fix that?
> 
> 
> Ok, I installed 2.8.96~2541-0ubuntu4~abstractsock15 which includes these
> patches, but I still see the setopt denials with cups ('sudo stop cups ; sudo
> start cups' will trigger it). I still can't make the denials go away with 'unix
> (setopt) type=stream peer=(addr=none)'.
>
This denial is different and I am still working on it, The new abstractsock13
kernel is a tiny step in that direction.

>> Also, I had a similar problem with getopt. Eg, I saw denials like this:
>> apparmor="DENIED" operation="getsockopt"
>> profile="/usr/lib/thunderbird/thunderbird{,*[^s][^h]}" pid=3798
>> comm="threaded-ml" family="unix" sock_type="stream" protocol=0
>> requested_mask="getopt" denied_mask="getopt" peer_name=none
>>
>> Yet this policy didn't make it go away:
>>   unix (getopt) type=stream peer=(addr=none),
>>
> Interestingly, I no longer see the getopt denial-- even *without* any rules for
> it. My test case was starting thunderbird without the dbus-session-strict
> abstraction, but now I don't see this. Not sure if this is tbird using a
> different code path or something with this patchset. If needed I can try with
> another set of apparmor patches (just let me know what to test).
> 
hrmmm, we will need to investigate more.