7:43 a.m.
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
1:29 p.m.
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(a)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
4:37 p.m.
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(a)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
6:57 a.m.
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
11:50 a.m.
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
1:29 p.m.
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...
3911
days inactive
3914
days old
linux-audit@lists.linux-audit.osci.io
6 comments
3 participants
participants (3)
-
Eric Paris -
Richard Guy Briggs -
Steve Grubb