Reading Audit Logs

+Reading Audit Logs + +Introduction + + +

+When working with a SELinux-enabled system, you will eventually notice t= hat +things behave differently, but without giving any meaningful error messa= ge. +Usually, when SELinux "denies" a particular access, it logs it into the = audit +log of the system, but for the application itself, it is perfectly possi= ble that +it just silently dies. If not, you're most likely to get a permission +denied error message. +

+ +

+Initially, SELinux is running in permissive mode, which means tha= t +SELinux will log what it would deny, but still let it through. +This mode is perfect for getting the system in shape without having too +much problems keeping it running. Once you think your security settings = are +in order, then this mode can be switched from permissive to +enforcing. We'll talk about these modes later. +

+ +

+First, let's take a look at the audit log and see what it is saying... +

+ + + + +Audit Log Location(s) + + +

+The SELinux kernel code writes its denials (and sometimes even allowed b= ut +audited activities) into the audit log. If you are running on a Gentoo H= ardened +installation with the syslog-ng system logger, then the logger is= already +configured to place these audit lines in /var/log/avc.log. = However, +different system loggers or system logger configurations might put the e= ntries +in a different log location (such as /var/log/audit.log). +

+ +

+Below, you'll find the appropriate lines for the syslog-ng system logger +configuration for writing the events in /var/log/avc.log. +

+ +

+# The following lines are only /part/ of the configuration file=
!
+source kernsrc  { file("/proc/kmsg");       };
+destination avc { file("/var/log/avc.log"); };
+filter f_avc    { message(".*avc: .*");     };
+
+log {
+  source(kernsrc);
+  filter(f_avc);
+  destination(avc);
+};
+

+ + + + +What is AVC? + + +

+As we mentioned, SELinux writes its entries in the audit log. These entr= ies are +called avc messages or avc log entries. The abbreviation A= VC +stands for Access Vector Cache and, like the name sais, is a cach= ing +system. +

+ +

+Using an access vector cache improves performance on dealing with (and +enforcing) activities and privileges. Since SELinux offers a very detail= ed +approach on privileges and permissions, it would become quite painful +(performance-wise) if each call means that the SELinux code needs to loo= k up the +domain, the target resource label, the privilege and if it is allowed or= not +over and over again. Instead, SELinux uses the Access Vector Cache to st= ore past +requests/responses. It is the AVC subsystem that is responsible for chec= king +accesses and (if necessary) logging it. +

+ + + + +Reading an AVC Denial Message + + +

+Below you'll find a typical AVC denial message. +

+ +

+Oct 15 13:04:54 hpl kernel: [963185.177043] type=3D1400 audit(1318676694=
.660:2472):=20
+  avc:  denied  { module_request } for  pid=3D14561 comm=3D"firefox" kmo=
d=3D"net-pf-10"
+  scontext=3Dstaff_u:staff_r:mozilla_t tcontext=3Dsystem_u:system_r:kern=
el_t tclass=3Dsystem
+

+ +

+Let's analyze each part of this message one by one. +

+ +

+Oct 15 13:04:54 hpl kernel: [963185.177043] type=3D1400 audit(131=
8676694.660:2472):=20
+  avc:  denied  { module_request } for  pid=3D14561 comm=3D"firefox" kmo=
d=3D"net-pf-10"
+  scontext=3Dstaff_u:staff_r:mozilla_t tcontext=3Dsystem_u:system_r:kern=
el_t tclass=3Dsystem
+

+ +

+This first part of the message informs you when the message was written = (Oct 15 +13:04:54), on which host (hpl) and how many seconds since the system was= booted +(963185.177043). +

+ +

+Oct 15 13:04:54 hpl kernel: [963185.177043] type=3D1400 audit(1318676694=
.660:2472):=20
+  avc:  denied  { module_request } for  pid=3D14561 comm=3D"firefox"<=
/i> kmod=3D"net-pf-10"
+  scontext=3Dstaff_u:staff_r:mozilla_t tcontext=3Dsystem_u:system=
_r:kernel_t tclass=3Dsystem
+

+ +
+Next is the source of the denial, i.e. what process is trying to do some= thing. +In this case, the process is firefox, with PID 14561, which is running i= n the +source domain staff_u:staff_r:mozilla_t. +
+ +
+Oct 15 13:04:54 hpl kernel: [963185.177043] type=3D1400 audit(1318676694= .660:2472):=20 + avc: denied { module_request } for pid=3D14561 comm=3D"firefox" = kmod=3D"net-pf-10" + scontext=3Dstaff_u:staff_r:mozilla_t tcontext=3Dsystem_u:system_r:k= ernel_t tclass=3Dsystem +
+ +
+The target of the activity is a kernel module (net-pf-10, which is the i= nternal +name given for IPv6), labeled system_u:system_r:kernel_t +
+ +
+Oct 15 13:04:54 hpl kernel: [963185.177043] type=3D1400 audit(1318676694= .660:2472):=20 + avc: denied { module_request } for pid=3D14561 comm=3D"firef= ox" kmod=3D"net-pf-10" + scontext=3Dstaff_u:staff_r:mozilla_t tcontext=3Dsystem_u:system_r:kern= el_t tclass=3Dsystem +
+ +
+Finally, the action that is denied (module_request) and its class (syste= m). +These classes help you to identify what is denied, because a read on a f= ile is +different from a read on a directory. +
+ +
+For instance, in the following case, a process gorg with PID 1393= 5 is +trying to read a file called localtime with inode 130867 wh= ich +resides on the device /dev/md3: +
+ +
+Oct 15 14:40:30 hpl kernel: [968909.807802] type=3D1400 audit(1318682430= .323:2614): + avc: denied { read } for pid=3D13935 comm=3D"gorg" name=3D"localtim= e" dev=3Dmd3 ino=3D130867 + scontext=3Dstaff_u:sysadm_r:gorg_t tcontext=3Dsystem_u:object_r:locale= _t tclass=3Dfile +
+ +
+In this case, it might be obvious that the file is /etc/localtime<= /path>, +but when that isn't the case, then you can find the following two comman= ds +useful: +
+ +
+(Find out which device /dev/md3 is) +# mount | grep /dev/md3 +/dev/md3 on / type ext4 (rw,seclabel,noatime,barrier=3D1,nodelalloc,data= =3Djournal) + +(Find out what file has inode 130867) +# find / -xdev -inum 130867 +/etc/localtime +
+ + + + +Handling AVC denials + + +
+The major part of configuring SELinux is reading the denials, finding ou= t what +needs to be fixed (or ignored), fix it, and repeat the steps. Hopefully,= the +rest of this handbook will help you figure out what is causing a denial. +
+ +
+Denials can be cosmetic (an activity that is denied, but has no effect o= n the +application's functional behaviour). If that is the case, the denial can= be +marked as dontaudit, meaning that the denial is not logged by def= ault +anymore. If you think that a denial is occurring but you do not see it i= n the +logs, try disabling the dontaudit rules: +
+ +
+(The command can also be abbreviated to "semodule -DB") +# semodule --build --disable_dontaudit +
+ +
+In most cases though, denials need to be acted upon. Actions that might = need to +happen are: +
+ +
+
+ relabeling the target resource (wrong labels might cause legitimate = actions + to be denied) +
+
+ relabeling the source (process' binary file) as a wrong label might = cause + the application to run in the wrong domain +
+
+ loading a necessary SELinux module, since the modules contain the ru= les to + allow (and label) resources. Without the appropriate module loaded, = you will + notice denials since no other module gives the necessary grants (all= ow + statements) +
+
+ granting the right role to the user executing the application. We ha= ve + covered users and their roles initially but we will go deeper into t= his + subject later in the handbook. +
+
+ adding your own SELinux policy statements, most likely because no SE= Linux + policy module exists for the application you are trying to run +
+
+ + + +