finit_module

finit_module

[Steve Grubb]

Hello,

In checking a system with newish kernel, 3.13.7, I noticed that sometimes 
finit_module is producing PATH records. Why?


type=PATH msg=audit(04/04/2014 07:28:45.177:408) : item=1 name=(null) 
inode=21788 dev=00:06 mode=dir,755 ouid=root ogid=root rdev=00:00 
obj=system_u:object_r:debugfs_t:s0 nametype=CREATE 
type=PATH msg=audit(04/04/2014 07:28:45.177:408) : item=0 name=(null) 
inode=165 dev=00:06 mode=dir,755 ouid=root ogid=root rdev=00:00 
obj=system_u:object_r:debugfs_t:s0 nametype=PARENT 
type=SYSCALL msg=audit(04/04/2014 07:28:45.177:408) : arch=x86_64 
syscall=finit_module success=yes exit=0 a0=0x0 a1=0x41a396 a2=0x0 a3=0x0 
items=1348 ppid=1369 pid=1370 auid=unset uid=root gid=root euid=root suid=root 
fsuid=root egid=root sgid=root fsgid=root ses=unset tty=(none) comm=modprobe 
exe=/usr/bin/kmod subj=system_u:system_r:insmod_t:s0 key=module-load

Also, when it does this, it makes a whole lot of them:

type=PATH msg=audit(04/04/2014 07:28:45.177:408) : item=1347 name=(null) 
inode=22461 dev=00:06 mode=dir,755 ouid=root ogid=root rde
v=00:00 obj=system_u:object_r:debugfs_t:s0 nametype=CREATE 

Seriously, 1347 auxiliary records? Why?

-Steve

Re: finit_module

[Richard Guy Briggs]

On 14/04/04, Steve Grubb wrote:
> Hello,
> 
> In checking a system with newish kernel, 3.13.7, I noticed that sometimes 
> finit_module is producing PATH records. Why?

Probably because modprobe is walking the
	/lib/modules/$(uname -r)/kernel/
tree looking for the module named.

But...  why are all the pathnames null?

> type=PATH msg=audit(04/04/2014 07:28:45.177:408) : item=1 name=(null) 
> inode=21788 dev=00:06 mode=dir,755 ouid=root ogid=root rdev=00:00 
> obj=system_u:object_r:debugfs_t:s0 nametype=CREATE 
> type=PATH msg=audit(04/04/2014 07:28:45.177:408) : item=0 name=(null) 
> inode=165 dev=00:06 mode=dir,755 ouid=root ogid=root rdev=00:00 
> obj=system_u:object_r:debugfs_t:s0 nametype=PARENT 
> type=SYSCALL msg=audit(04/04/2014 07:28:45.177:408) : arch=x86_64 
> syscall=finit_module success=yes exit=0 a0=0x0 a1=0x41a396 a2=0x0 a3=0x0 
> items=1348 ppid=1369 pid=1370 auid=unset uid=root gid=root euid=root suid=root 
> fsuid=root egid=root sgid=root fsgid=root ses=unset tty=(none) comm=modprobe 
> exe=/usr/bin/kmod subj=system_u:system_r:insmod_t:s0 key=module-load
> 
> Also, when it does this, it makes a whole lot of them:
> 
> type=PATH msg=audit(04/04/2014 07:28:45.177:408) : item=1347 name=(null) 
> inode=22461 dev=00:06 mode=dir,755 ouid=root ogid=root rde
> v=00:00 obj=system_u:object_r:debugfs_t:s0 nametype=CREATE 
> 
> Seriously, 1347 auxiliary records? Why?
> 
> -Steve

- RGB

--
Richard Guy Briggs <rbriggs@redhat.com>
Senior Software Engineer, Kernel Security, AMER ENG Base Operating Systems, Red Hat
Remote, Ottawa, Canada
Voice: +1.647.777.2635, Internal: (81) 32635, Alt: +1.613.693.0684x3545

Re: finit_module

[Richard Guy Briggs]

On 14/04/04, Richard Guy Briggs wrote:
> On 14/04/04, Steve Grubb wrote:
> > Hello,
> > 
> > In checking a system with newish kernel, 3.13.7, I noticed that sometimes 
> > finit_module is producing PATH records. Why?
> 
> Probably because modprobe is walking the
> 	/lib/modules/$(uname -r)/kernel/
> tree looking for the module named.

Is modprobe forcing a depmod to run, populating:
	/lib/modules/$(uname -r)/modules.*

Does this happen at most once per boot?

> But...  why are all the pathnames null?

Did you try to track down what some of the dev/inode pathnames were?

The number does seem high for this though, since they appear to all be
CREATE records.


Do you have a test to provoke it?  A set of rules and a test command?

> > type=PATH msg=audit(04/04/2014 07:28:45.177:408) : item=1 name=(null) 
> > inode=21788 dev=00:06 mode=dir,755 ouid=root ogid=root rdev=00:00 
> > obj=system_u:object_r:debugfs_t:s0 nametype=CREATE 
> > type=PATH msg=audit(04/04/2014 07:28:45.177:408) : item=0 name=(null) 
> > inode=165 dev=00:06 mode=dir,755 ouid=root ogid=root rdev=00:00 
> > obj=system_u:object_r:debugfs_t:s0 nametype=PARENT 
> > type=SYSCALL msg=audit(04/04/2014 07:28:45.177:408) : arch=x86_64 
> > syscall=finit_module success=yes exit=0 a0=0x0 a1=0x41a396 a2=0x0 a3=0x0 
> > items=1348 ppid=1369 pid=1370 auid=unset uid=root gid=root euid=root suid=root 
> > fsuid=root egid=root sgid=root fsgid=root ses=unset tty=(none) comm=modprobe 
> > exe=/usr/bin/kmod subj=system_u:system_r:insmod_t:s0 key=module-load
> > 
> > Also, when it does this, it makes a whole lot of them:
> > 
> > type=PATH msg=audit(04/04/2014 07:28:45.177:408) : item=1347 name=(null) 
> > inode=22461 dev=00:06 mode=dir,755 ouid=root ogid=root rde
> > v=00:00 obj=system_u:object_r:debugfs_t:s0 nametype=CREATE 
> > 
> > Seriously, 1347 auxiliary records? Why?
> > 
> > -Steve
> 
> - RGB

- RGB

--
Richard Guy Briggs <rbriggs@redhat.com>
Senior Software Engineer, Kernel Security, AMER ENG Base Operating Systems, Red Hat
Remote, Ottawa, Canada
Voice: +1.647.777.2635, Internal: (81) 32635, Alt: +1.613.693.0684x3545

Re: finit_module

[Steve Grubb]

On Friday, April 04, 2014 05:37:25 PM Richard Guy Briggs wrote:
> > > In checking a system with newish kernel, 3.13.7, I noticed that
> > > sometimes 
> > > finit_module is producing PATH records. Why?
> >
> > Probably because modprobe is walking the
> >       /lib/modules/$(uname -r)/kernel/
> > tree looking for the module named.
> 
> Is modprobe forcing a depmod to run, populating:
>         /lib/modules/$(uname -r)/modules.*

No idea, because we don't know which module is being loaded. It seems like we 
might could use an auxiliary record to log some information about the module 
being inserted into the kernel. Like if it has an internal name, is it signed, 
did it taint the kernel, did the signature verify correctly?


> Does this happen at most once per boot?

There are several.


> > But...  why are all the pathnames null?
> 
> Did you try to track down what some of the dev/inode pathnames were?

No. I don't use debugfs...which is the only good clue I have.

> The number does seem high for this though, since they appear to all be
> CREATE records.
> 
> Do you have a test to provoke it?  A set of rules and a test command?

Just enable the stig.rule and reboot your system. It has:

-w /sbin/insmod -p x -k modules-add
-w /sbin/rmmod -p x -k modules-del
-w /sbin/modprobe -p x -k modules
-a always,exit -F arch=b32 -S init_module -S finit_module -k module-load
-a always,exit -F arch=b64 -S init_module -S finit_module -k module-load
-a always,exit -F arch=b32 -S delete_module -k module-unload
-a always,exit -F arch=b64 -S delete_module -k module-unload


-Steve

Re: finit_module

[Eric Paris]

On Fri, 2014-04-04 at 08:43 -0400, Steve Grubb wrote:
> Hello,
> 
> In checking a system with newish kernel, 3.13.7, I noticed that sometimes 
> finit_module is producing PATH records. Why?

Because the module created all of those files while it was loading...

Re: finit_module

[Steve Grubb]

On Monday, April 07, 2014 12:37:48 PM Eric Paris wrote:
> On Fri, 2014-04-04 at 08:43 -0400, Steve Grubb wrote:
> > Hello,
> > 
> > In checking a system with newish kernel, 3.13.7, I noticed that sometimes
> > finit_module is producing PATH records. Why?
> 
> Because the module created all of those files while it was loading...

Hmm...I don't think what we are getting is expected or useful. It would be 
nice to know what the paths are instead of NULL. It would also be highly 
desirable to get some basic information recorded about what module is getting 
loaded in an aux record. Especially since loading modules are how system tap 
and some of the kernel bug patching tools get loaded.

-Steve

Re: finit_module

[Eric Paris]

On Mon, 2014-04-07 at 12:50 -0400, Steve Grubb wrote:
> On Monday, April 07, 2014 12:37:48 PM Eric Paris wrote:
> > On Fri, 2014-04-04 at 08:43 -0400, Steve Grubb wrote:
> > > Hello,
> > > 
> > > In checking a system with newish kernel, 3.13.7, I noticed that sometimes
> > > finit_module is producing PATH records. Why?
> > 
> > Because the module created all of those files while it was loading...
> 
> Hmm...I don't think what we are getting is expected or useful. It would be 
> nice to know what the paths are instead of NULL.

Is every single record NULL?  I felt like it once upon a time had some
information....   Usually these are files in debugfs and sysfs being
created by the module load.

>  It would also be highly 
> desirable to get some basic information recorded about what module is getting 
> loaded in an aux record.

Might be do-able to get something from the module header...

with finit_module (as opposed to init_module) we probably can get
something about the file descriptor...

>  Especially since loading modules are how system tap 
> and some of the kernel bug patching tools get loaded.

Not sure how reliable/useful these fields are, but we can possibly get
something...