Re: [gentoo-hardened] Unsolved AVCs on a hardened/linux/amd64/selinux

[Vincent Brillault]

On Fri  2.Mar'12 at 18:59:14 +0000, Sven Vermeulen wrote:
> > Mar  2 10:54:51 ***** kernel: [    8.354336] type=1400
> > audit(1330682087.785:7): avc:  denied  { write } for  pid=1062 comm="rm"
> > name="console" dev="sda1" ino=423795 scontext=system_u:system_r:initrc_t
> > tcontext=system_u:object_r:lib_t tclass=dir
>
> Any idea what it is trying to delete here? I think it is something in
> /lib(64)/rc/console (gut feeling) but I don't know what it is. At least, I
> don't get those, but that might be because the system doesn't get here in
> enforcing mode (i.e. earlier denials are prohibiting it from reaching this
> point).

Perhaps, yes... I'll try to boot in enforcing mode when violent denials
will be solved. 

> > Mar  2 10:54:51 ***** kernel: [    8.354358] type=1400
> > audit(1330682087.785:8): avc:  denied  { remove_name } for  pid=1062
> > comm="rm" name="keymap" dev="sda1" ino=393305
> > scontext=system_u:system_r:initrc_t tcontext=system_u:object_r:lib_t
> > tclass=dir
> > Mar  2 10:54:51 ***** kernel: [    8.354373] type=1400
> > audit(1330682087.785:9): avc:  denied  { unlink } for  pid=1062
> > comm="rm" name="keymap" dev="sda1" ino=393305
> > scontext=system_u:system_r:initrc_t tcontext=system_u:object_r:lib_t
> > tclass=file
>
> I think these are related with the earlier one.
>
Correct, it seems it's trying to remove  "/lib64/rc/console/keymap":

type=AVC msg=audit(1330777582.322:10): avc:  denied  { write } for
pid=1102 comm="rm" name="console" dev="sda1" ino=423795
scontext=system_u:system_r:initrc_t tcontext=system_u:object_r:lib_t
tclass=dir
type=AVC msg=audit(1330777582.322:10): avc:  denied  { remove_name } for
pid=1102 comm="rm" name="keymap" dev="sda1" ino=393305
scontext=system_u:system_r:initrc_t tcontext=system_u:object_r:lib_t
tclass=dir
type=AVC msg=audit(1330777582.322:10): avc:  denied  { unlink } for
pid=1102 comm="rm" name="keymap" dev="sda1" ino=393305
scontext=system_u:system_r:initrc_t tcontext=system_u:object_r:lib_t
tclass=file
type=SYSCALL msg=audit(1330777582.322:10): arch=c000003e syscall=263
success=yes exit=0 a0=ffffffffffffff9c a1=6d4752bda0 a2=0
a3=6f63696e752f65 items=2 ppid=1096 pid=1102 auid=4294967295 uid=0 gid=0
euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=tty1 ses=4294967295
comm="rm" exe="/bin/rm" subj=system_u:system_r:initrc_t key=(null)
type=PATH msg=audit(1330777582.322:10): item=0 name="/lib64/rc/console/"
inode=423795 dev=08:01 mode=040755 ouid=0 ogid=0 rdev=00:00
obj=system_u:object_r:lib_t
type=PATH msg=audit(1330777582.322:10): item=1
name="/lib64/rc/console/keymap" inode=393305 dev=08:01 mode=0100644
ouid=0 ogid=0 rdev=00:00 obj=system_u:object_r:lib_t


> > Mar  2 10:54:51 ***** kernel: [    8.365926] type=1400
> > audit(1330682087.796:10): avc:  denied  { create } for  pid=1063
> > comm="mkdir" name=".test.1056" scontext=system_u:system_r:initrc_t
> > tcontext=system_u:object_r:var_run_t tclass=dir
>
> This means an init script (source context is "initrc_t") is trying to create
> a directory most likely in /var/run. If you could find out which init script
> it is? Creating temporary directories there isn't exactly a good practice,
> even though I think it is merely checking (in the init script) if the script
> can write there.

Found it, it's in /etc/init.d/bootmisc:
The dir_writable() creates and removes it, when it's called on "/var/run"
It's clearly a test. It's perhaps linked to the fuser avc as this test
conditions some fuser invocations:
'''
  if type fuser >/dev/null 2>&1; then
    fuser "$x" >/dev/null 2>&1 || rm -- "$x"
'''

> For more information about SELinux bug reporting, please see
> http://www.gentoo.org/proj/en/hardened/selinux-bugreporting.xml

Sorry about that first mail with all these unsorted denials.

-------

Concerning asterisk (version 1.8.8.2 with selinux module 1.10.0
(selinux-asterisk 2.20120215)):

--

type=AVC msg=audit(1330764560.260:48): avc:  denied  { add_name } for
pid=1860 comm="runscript.sh" name="wrapper_loop.pid"
scontext=system_u:system_r:initrc_t
tcontext=system_u:object_r:asterisk_var_run_t tclass=dir
type=AVC msg=audit(1330764560.260:48): avc:  denied  { create } for
pid=1860 comm="runscript.sh" name="wrapper_loop.pid"
scontext=system_u:system_r:initrc_t
tcontext=system_u:object_r:asterisk_var_run_t tclass=file
type=AVC msg=audit(1330764560.260:48): avc:  denied  { write } for
pid=1860 comm="runscript.sh" name="wrapper_loop.pid" dev="sda1"
ino=524353 scontext=system_u:system_r:initrc_t
tcontext=system_u:object_r:asterisk_var_run_t tclass=file
type=SYSCALL msg=audit(1330764560.260:48): arch=c000003e syscall=2
success=yes exit=3 a0=304f144be0 a1=241 a2=1b6 a3=304eead429 items=2
ppid=1857 pid=1860 auid=4294967295 uid=0 gid=0 euid=0 suid=0
fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295
comm="runscript.sh" exe="/bin/bash" subj=system_u:system_r:initrc_t
key=(null)
type=PATH msg=audit(1330764560.260:48): item=0 name="/var/run/asterisk/"
inode=568583 dev=08:01 mode=040770 ouid=103 ogid=205 rdev=00:00
obj=system_u:object_r:asterisk_var_run_t
type=PATH msg=audit(1330764560.260:48): item=1
name="/var/run/asterisk/wrapper_loop.pid" inode=524353 dev=08:01
mode=0100644 ouid=0 ogid=0 rdev=00:00
obj=system_u:object_r:asterisk_var_run_t

I think that it directly comes from the init script that contains:
cut -f4 -d' ' < /proc/self/stat > /var/run/asterisk/wrapper_loop.pid

This error only impacts the init script and not the asterisk process.
I don't know what's the better way to fix that. Perhaps by moving this
file somewhere where it can have a initrc_* context.  

In enforcing mode, it obviously results in (but doesn't crash the
application):
Mar  3 11:36:12 ***** asterisk_wrapper: Initializing asterisk wrapper
Mar  3 11:36:12 ***** asterisk_wrapper: /etc/init.d/asterisk: line 35:
/var/run/asterisk/wrapper_loop.pid: Permission denied

--

Then we have a denied 'setattr', here is the verbose audit:

type=AVC msg=audit(1330764560.503:50): avc:  denied  { setattr } for
pid=1861 comm="asterisk" name="asterisk" dev="sda1" ino=568583
scontext=system_u:system_r:asterisk_t
tcontext=system_u:object_r:asterisk_var_run_t tclass=dir
type=SYSCALL msg=audit(1330764560.503:50): arch=c000003e syscall=92
success=yes exit=0 a0=287bab7e0 a1=67 a2=ffffffff a3=0 items=1 ppid=1857
pid=1861 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0
egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="asterisk"
exe="/usr/sbin/asterisk" subj=system_u:system_r:asterisk_t key=(null)
type=PATH msg=audit(1330764560.503:50): item=0 name="/var/run/asterisk"
inode=568583 dev=08:01 mode=040770 ouid=103 ogid=205 rdev=00:00
obj=system_u:object_r:asterisk_var_run_t

from the source code, we have:
'''
  if (runuser && !ast_test_flag(&ast_options, AST_OPT_FLAG_REMOTE)) {
    ...
    if (chown(ast_config_AST_RUN_DIR, pw->pw_uid, -1)) {
      ast_log(LOG_WARNING, "Unable to chown run directory to %d (%s)\n",
      (int) pw->pw_uid, runuser);
    }
'''

In enforcing mode, it results in:
"Unable to chown run directory to 103 (asterisk)"

This error could probably be ignored (dontaudit ?) as the ebuild
contains:
diropts -m 0770 -o asterisk -g asterisk
...
keepdir /var/run/asterisk

Nevertheless, for people that don't use the default run directory or
default user it could result in errors... 

--

In enforcing mode, asterisk can start but won't work. The deny is only
visible if I disable dontaudit rules:

==> /var/log/avc.log <==
Mar  3 12:51:28 .... kernel: [  374.048619] type=1400
audit(1330775488.478:103): avc:  denied  { name_bind } for  pid=2591
comm="asterisk" src=10290 ipaddr=***.***.***.***
scontext=system_u:system_r:asterisk_t
tcontext=system_u:object_r:unreserved_port_t tclass=udp_socket

==> /var/log/asterisk/full <==
[Mar  3 12:51:28] ERROR[2591] res_rtp_asterisk.c: Oh dear... we couldn't
allocate a port for RTP instance '0x339d0007688'
[Mar  3 12:51:28] NOTICE[2591] chan_sip.c: Failed to authenticate device

I don't know if we want to make asterisk able to bind on unreserved
ports or a somehow more precise range (the range in which this port can
be allocated is defined in rtp.conf) 

-----

Concerning the sysfs bug, it seems related to /sys/fs/selinux:
type=AVC msg=audit(1330778502.425:149): avc:  denied  { search } for
pid=2514 comm="unix_chkpwd" name="/" dev="sysfs" ino=1
ipaddr=194.29.25.170 scontext=staff_u:staff_r:chkpwd_t
tcontext=system_u:object_r:sysfs_t tclass=dir
type=SYSCALL msg=audit(1330778502.425:149): arch=c000003e syscall=137
success=no exit=-13 a0=26fff23a6a7 a1=3ce4d3efb50 a2=fffffffffff6c3f7
a3=5 items=1 ppid=2513 pid=2514 auid=1000 uid=1000 gid=1000 euid=0
suid=0 fsuid=0 egid=1000 sgid=1000 fsgid=1000 tty=pts2 ses=10
comm="unix_chkpwd" exe="/sbin/unix_chkpwd" subj=staff_u:staff_r:chkpwd_t
key=(null)
type=PATH msg=audit(1330778502.425:149): item=0 name="/sys/fs/selinux"

"/sys/fs/selinux" does exist but don't contain anything 

-----

I'll continue to try to identify and fix the avc I have,

Sincerely yours,
Vincent Brillault