Re: [PATCH] audit: set TIF_AUDIT_SYSCALL only if audit filter has been populated

[Paul Moore]

On Wed, Mar 7, 2018 at 6:41 PM, Paul Moore  wrote:
> On Wed, Mar 7, 2018 at 11:48 AM, Jiri Kosina  wrote:
>> On Wed, 7 Mar 2018, Andy Lutomirski wrote:
>>> Wow, this was a long time ago.
>>
>> Oh yeah; but it now resurfaced on our side, as we are of course receiving
>> a lot of requests with respect to making syscall performance great again
>> :)
>
> Ooof.  I'm not sure I can handle making more things "great again" ;)
>
>>> From memory and a bit of email diving, there are two reasons.
>>>
>>> 1. The probably was partially solved (by Oleg, IIRC) by making auditctl
>>>-a task,never cause newly spawned tasks to not suck.  Yes, it's a
>>>very partial solution.  After considerable nagging, I got Fedora to
>>>default to -a task,never.
>>
>> Hm, right; that's a bit inconvenient, because it takes each and every
>> vendor having to realize this option, and put it in. Making kernel do the
>> right thing automatically sounds like a better option to me.
>
> This predates audit falling into my lap, but speaking generally I
> think it would be good if the kernel did The Right Thing, so long as
> it isn't too painful.
>
>>> 2. This patch, as is, may be a bit problematic.  In particular, if one
>>>task changes the audit rules while another task is in the middle of
>>>the syscall, then it's too late to audit that syscall correctly.
>>>This could be seen as a bug or it could be seen as being just fine.
>>
>> I don't think this should be a problem, given the fact that the whole
>> timing/ordering is not predictable anyway due to scheduling.
>>
>> Paul, what do you think?
>
> I'm not overly concerned about the race condition between configuring
> the audit filters and syscalls that are currently in-flight; after all
> we have that now and "fixing" it would be pretty much impractical
> (impossible maybe?).  Most serious audit users configure it during
> boot and let it run, frequent runtime changes are not common as far as
> I can tell.
>
> I just looked quickly at the patch and decided it isn't something I'm
> going to be able to carefully review in the time I've got left today,
> so it's going to have to wait until tomorrow and Friday ... however,
> speaking on general principle I don't have an objection to the ideas
> put forth here.
>
> Andy, if you've got any Reviewed-by/Tested-by/NACK/etc. you want to
> add, that would be good to have.

... and I just realized that linux-audit isn't on the To/CC line,
adding them now.

Link to the patch is below.

* https://marc.info/?t=15204188763=1=2

-- 
paul moore
www.paul-moore.com

--
Linux-audit mailing list
Linux-audit@redhat.com
https://www.redhat.com/mailman/listinfo/linux-audit

Re: audit watch rules and docker containers

[Richard Guy Briggs]

On 2018-03-05 21:39, Rakesh wrote:
> Hi Richard,
> 
> Thanks for reviewing the email and my apologies for the formatting
> issue. This response corrects that.

(I don't see any format correction in this response.)

> I looked at Steve's response (with the embedded link) and have also
> followed your presentation on youtube however I am not clear on the
> proposed change(s) which will allow the mnt space to be shared between
> the host and the privileged container. Is this use case even being
> considered?

I don't understand what you mean by a mount namespace being shared by
the host and the privileged container.  They are distinct mount
namespaces.  They aren't shared.  If you find the device and inode
numbers of the same path in different mount namespaces the device number
at minimum will be different.  If you change one file, the other is not
affected.

> Thanks,
> Rakesh
> 
> 
> 
> 
> From: Richard Guy Briggs 
> To: Rakesh  
> Cc: "linux-audit@redhat.com" 
> Sent: Sunday, March 4, 2018 11:14 PM
> Subject: Re: audit watch rules and docker containers
> 
> 
> On 2018-03-03 08:52, Rakesh wrote:
> > Hello Auditd'ers,
> 
> Hi Rakesh,
> (I see, with difficulty, that your output is well-formatted in the HTML
> attachment, but that isn't useful.  Please shut off HTML message
> formatting and ensure that it looks right in plain text.  Also, please
> use "ls -l" so it sorts in a meaningful order for comparison.)
> 
> > I am running a privileged container with pid, net, uts space shared with 
> > the host. The need is to be able to set file watch rules from the container 
> > say 
> > -k /etc -p rw -k containter_rule
> > and then look for read/write access to files/directories in 
> > /var/log/audit/*.
> > What I am finding is there are no watch events being logged
> > If I set the same audit watch rule from the host (and not being in the 
> > privileged container) I am able to get audit events
> > Using nsenter to switch namespace (nsenter -t 1 auditctl -k /etc -p rw -k 
> > containter_rule) does not help either
> > I suspect the mnt namespace is different which is causing this oddity in 
> > behavior
> > looking at container process namespace -
> > test@ubuntu-16:~/audit$ sudo ls -latr  /proc/26050/ns[sudo] password for 
> > test:total 0dr-xr-xr-x 9 root root 0 Mar  2 16:58 ..dr-x--x--x 2 root root 
> > 0 Mar  2 17:46 .lrwxrwxrwx 1 root root 0 Mar  2 17:46 uts -> 
> > uts:[4026531838]lrwxrwxrwx 1 root root 0 Mar  2 17:46 user -> 
> > user:[4026531837]lrwxrwxrwx 1 root root 0 Mar  2 17:46 pid -> 
> > pid:[4026531836]lrwxrwxrwx 1 root root 0 Mar  2 17:46 net -> 
> > net:[4026531957]lrwxrwxrwx 1 root root 0 Mar  2 17:46 mnt -> 
> > mnt:[4026532517]lrwxrwxrwx 1 root root 0 Mar  2 17:46 ipc -> 
> > ipc:[4026532518]lrwxrwxrwx 1 root root 0 Mar  2 17:46 cgroup -> 
> > cgroup:[4026531835]
> > looking at init process namespace -
> > 
> > test@ubuntu-16:~/audit$ sudo ls -latr  /proc/1/nstotal 0dr-xr-xr-x 9 root 
> > root 0 Mar  2 10:37 ..lrwxrwxrwx 1 root root 0 Mar  2 10:38 mnt -> 
> > mnt:[4026531840]dr-x--x--x 2 root root 0 Mar  2 10:38 .lrwxrwxrwx 1 root 
> > root 0 Mar  2 16:47 uts -> uts:[4026531838]lrwxrwxrwx 1 root root 0 Mar  2 
> > 16:47 user -> user:[4026531837]lrwxrwxrwx 1 root root 0 Mar  2 16:47 pid -> 
> > pid:[4026531836]lrwxrwxrwx 1 root root 0 Mar  2 16:47 net -> 
> > net:[4026531957]lrwxrwxrwx 1 root root 0 Mar  2 16:47 ipc -> 
> > ipc:[4026531839]lrwxrwxrwx 1 root root 0 Mar  2 16:47 cgroup -> 
> > cgroup:[4026531835]
> 
> After decoding your jumbled mess of output due to HTML and ls options
> choices, the mount namespaces are different, which would completely
> explain the problem.
> 
> > Can someone please suggest with some thoughts on how to make this work.
> 
> The pending container support mentioned by Steve is not yet complete and
> some more of the coming changes may help with your issue, but start by
> understanding that you are examining different filesystems with your
> rules above.
> 
> 
> > Thanks,Rakesh  
> 
> - RGB

- RGB

--
Richard Guy Briggs 
Sr. S/W Engineer, Kernel Security, Base Operating Systems
Remote, Ottawa, Red Hat Canada
IRC: rgb, SunRaycer
Voice: +1.647.777.2635, Internal: (81) 32635

--
Linux-audit mailing list
Linux-audit@redhat.com
https://www.redhat.com/mailman/listinfo/linux-audit