Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: Gentoo: Hardened

Unsolved AVCs on a hardened/linux/amd64/selinux

 

 

Gentoo hardened RSS feed   Index | Next | Previous | View Threaded


gentoo at lerya

Mar 2, 2012, 2:13 AM

Post #1 of 4 (834 views)
Permalink
Unsolved AVCs on a hardened/linux/amd64/selinux

Hi all,

I've installed my first SELinux enhanced Gentoo Hardened a few days
ago.
A lot of avc appears in the logs and I fear that those would crash the
server if I try to boot in enforcing mode.

Basic configuration details :
Kernel: 3.2.2-hardened-r1
Profile: hardened/linux/amd64/selinux
sec-policy: based on the hardened-dev overlay:
- sec-policy/selinux-base-policy: 2.20120215-r4
- sec-policy/selinux-base: 2.20120215-r4
Policy: strict
Mode: permissive

First of all, I think that the current policy lakes a context rules for
ip6tables, I fixed it by adding the following rule (The context used
here comes from /var/lib/iptables):
/var/lib/ip6tables(/.*)? gen_context(system_u:object_r:initrc_tmp_t)

Then, another rule seems to be missing from nginx. I think it's caused
by a the following line in my configuration: “include
/etc/nginx/vhosts.d/*.conf;” that result in :
Mar 2 11:10:47 ***** kernel: [ 968.008780] type=1400
audit(1330683047.439:55): avc: denied { read } for pid=2257
comm="nginx" name="vhosts.d" dev="sda1" ino=393764
scontext=system_u:system_r:nginx_t
tcontext=system_u:object_r:nginx_conf_t tclass=dir

I added the following rule to resolve this avc:
allow nginx_t nginx_conf_t:dir read;

I don't have enough experience to understand the following avcs that
come after every boot (after I log in) :

Mar 2 10:54:51 ***** kernel: [ 3.669361] type=1400
audit(1330682082.668:3): avc: denied { getattr } for pid=736
comm="mount" name="/" dev="sysfs" ino=1
scontext=system_u:system_r:mount_t tcontext=system_u:object_r:sysfs_t
tclass=filesystem
Mar 2 10:54:51 ***** kernel: [ 3.803100] type=1400
audit(1330682082.802:4): avc: denied { getattr } for pid=751
comm="restorecon" name="/" dev="sysfs" ino=1
scontext=system_u:system_r:setfiles_t tcontext=system_u:object_r:sysfs_t
tclass=filesystem
Mar 2 10:54:51 ***** kernel: [ 6.859414] type=1400
audit(1330682086.290:5): avc: denied { getattr } for pid=968
comm="pvscan" name="/" dev="sysfs" ino=1
scontext=system_u:system_r:lvm_t tcontext=system_u:object_r:sysfs_t
tclass=filesystem
Mar 2 10:54:51 ***** kernel: [ 7.767982] type=1400
audit(1330682087.198:6): avc: denied { setsched } for pid=1010
comm="mount" scontext=system_u:system_r:mount_t
tcontext=system_u:system_r:kernel_t tclass=process
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
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
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
Mar 2 10:54:51 ***** kernel: [ 8.719682] type=1400
audit(1330682088.150:11): avc: denied { getattr } for pid=1175
comm="fuser" path="socket:[1859]" dev="sockfs" ino=1859
scontext=system_u:system_r:initrc_t tcontext=system_u:system_r:udev_t
tclass=unix_stream_socket
Mar 2 10:54:51 ***** kernel: [ 8.720802] type=1400
audit(1330682088.151:12): avc: denied { getattr } for pid=1176
comm="fuser" path="socket:[1860]" dev="sockfs" ino=1860
scontext=system_u:system_r:initrc_t tcontext=system_u:system_r:udev_t
tclass=netlink_kobject_uevent_socket
Mar 2 10:54:51 ***** kernel: [ 8.849343] type=1400
audit(1330682088.280:13): avc: denied { setattr } for pid=1271
comm="chmod" name="/" dev="tmpfs" ino=3021
scontext=system_u:system_r:initrc_t tcontext=system_u:object_r:tmp_t
tclass=dir
Mar 2 10:54:51 ***** kernel: [ 9.151457] type=1400
audit(1330682088.582:14): avc: denied { add_name } for pid=1299
comm="runscript.sh" name="unicode" scontext=system_u:system_r:initrc_t
tcontext=system_u:object_r:lib_t tclass=dir
Mar 2 10:54:54 ***** kernel: [ 15.470860] type=1400
audit(1330682094.901:22): avc: denied { getattr } for pid=1735
comm="openvpn" name="/" dev="sysfs" ino=1
scontext=system_u:system_r:openvpn_t tcontext=system_u:object_r:sysfs_t
tclass=filesystem
Mar 2 10:54:56 ***** kernel: [ 16.646182] type=1400
audit(1330682096.077:23): avc: denied { add_name } for pid=1804
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
Mar 2 10:54:56 ***** kernel: [ 16.646272] type=1400
audit(1330682096.077:24): avc: denied { create } for pid=1804
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
Mar 2 10:54:56 ***** kernel: [ 16.646389] type=1400
audit(1330682096.077:25): avc: denied { write } for pid=1804
comm="runscript.sh" name="wrapper_loop.pid" dev="sda1" ino=524346
scontext=system_u:system_r:initrc_t
tcontext=system_u:object_r:asterisk_var_run_t tclass=file
Mar 2 10:54:56 ***** kernel: [ 16.903405] type=1400
audit(1330682096.334:26): avc: denied { setattr } for pid=1805
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
Mar 2 10:54:58 ***** kernel: [ 19.082552] type=1400
audit(1330682098.513:27): avc: denied { getattr } for pid=1838
comm="mount" name="/" dev="sysfs" ino=1
scontext=system_u:system_r:mount_t tcontext=system_u:object_r:sysfs_t
tclass=filesystem
Mar 2 10:54:58 ***** kernel: [ 19.340996] type=1400
audit(1330682098.772:28): avc: denied { dac_override } for pid=1865
comm="nginx" capability=1 scontext=system_u:system_r:nginx_t
tcontext=system_u:system_r:nginx_t tclass=capability
Mar 2 10:54:59 ***** kernel: [ 20.095608] type=1400
audit(1330682099.526:29): avc: denied { getattr } for pid=1895
comm="sed" name="/" dev="sysfs" ino=1
scontext=system_u:system_r:postfix_master_t
tcontext=system_u:object_r:sysfs_t tclass=filesystem
Mar 2 10:55:12 ***** kernel: [ 33.256625] type=1400
audit(1330682112.687:30): avc: denied { search } for pid=2033
comm="unix_chkpwd" name="/" dev="sysfs" ino=1 ipaddr=***.***.***.***
scontext=system_u:system_r:chkpwd_t tcontext=system_u:object_r:sysfs_t
tclass=dir
Mar 2 10:55:12 ***** kernel: [ 33.256688] type=1400
audit(1330682112.687:31): avc: denied { getattr } for pid=2033
comm="unix_chkpwd" name="/" dev="sysfs" ino=1 ipaddr=***.***.***.***
scontext=system_u:system_r:chkpwd_t tcontext=system_u:object_r:sysfs_t
tclass=filesystem
Mar 2 10:55:14 ***** kernel: [ 35.354952] type=1400
audit(1330682114.785:32): avc: denied { search } for pid=2042
comm="unix_chkpwd" name="/" dev="sysfs" ino=1 ipaddr=***.***.***.***
scontext=staff_u:staff_r:chkpwd_t tcontext=system_u:object_r:sysfs_t
tclass=dir
Mar 2 10:55:14 ***** kernel: [ 35.355060] type=1400
audit(1330682114.786:33): avc: denied { getattr } for pid=2042
comm="unix_chkpwd" name="/" dev="sysfs" ino=1 ipaddr=***.***.***.***
scontext=staff_u:staff_r:chkpwd_t tcontext=system_u:object_r:sysfs_t
tclass=filesystem
Mar 2 10:55:19 ***** kernel: [ 39.687063] type=1400
audit(1330682119.117:34): avc: denied { transition } for pid=2045
comm="newrole" path="/bin/zsh" dev="sda1" ino=563099
ipaddr=***.***.***.*** scontext=staff_u:staff_r:newrole_t
tcontext=staff_u:sysadm_r:sysadm_t tclass=process
Mar 2 10:55:19 ***** kernel: [ 39.687937] type=1400
audit(1330682119.118:35): avc: denied { rlimitinh } for pid=2045
comm="zsh" ipaddr=***.***.***.*** scontext=staff_u:staff_r:newrole_t
tcontext=staff_u:sysadm_r:sysadm_t tclass=process
Mar 2 10:55:19 ***** kernel: [ 39.687958] type=1400
audit(1330682119.118:36): avc: denied { siginh } for pid=2045
comm="zsh" ipaddr=***.***.***.*** scontext=staff_u:staff_r:newrole_t
tcontext=staff_u:sysadm_r:sysadm_t tclass=process
Mar 2 10:55:19 ***** kernel: [ 39.689198] type=1400
audit(1330682119.120:37): avc: denied { noatsecure } for pid=2045
comm="zsh" ipaddr=***.***.***.*** scontext=staff_u:staff_r:newrole_t
tcontext=staff_u:sysadm_r:sysadm_t tclass=process
Mar 2 10:55:19 ***** kernel: [ 39.714856] type=1400
audit(1330682119.145:38): avc: denied { getattr } for pid=2045
comm="sudo" name="/" dev="sysfs" ino=1 ipaddr=***.***.***.***
scontext=staff_u:sysadm_r:sysadm_sudo_t
tcontext=system_u:object_r:sysfs_t tclass=filesystem
Mar 2 10:55:19 ***** kernel: [ 39.812201] type=1400
audit(1330682119.243:39): avc: denied { search } for pid=2046
comm="unix_chkpwd" name="/" dev="sysfs" ino=1 ipaddr=***.***.***.***
scontext=staff_u:sysadm_r:chkpwd_t tcontext=system_u:object_r:sysfs_t
tclass=dir
Mar 2 10:55:19 ***** kernel: [ 39.812263] type=1400
audit(1330682119.243:40): avc: denied { getattr } for pid=2046
comm="unix_chkpwd" name="/" dev="sysfs" ino=1 ipaddr=***.***.***.***
scontext=staff_u:sysadm_r:chkpwd_t tcontext=system_u:object_r:sysfs_t
tclass=filesystem


More information concerning my configuration:
#semodule -l
apache 2.3.0
application 1.2.0
asterisk 1.10.0
authlogin 2.3.0
bind 1.11.0
bootloader 1.13.0
clock 1.6.0
consoletype 1.10.0
cron 2.4.0
crontabr2e 1.0.0
dmesg 1.3.0
fixes 1.0.0 (ip6table fix)
fstools 1.15.0
getty 1.9.0
hostname 1.7.0
hotplug 1.15.0
init 1.18.0
iptables 1.13.0
libraries 2.8.0
locallogin 1.11.0
logging 1.18.0
logrotate 1.14.0
lvm 1.13.0
miscfiles 1.9.0
modutils 1.12.0
mount 1.14.0
mta 2.4.0
netutils 1.11.0
nginx 1.0.10
nginxfix 1.0.10
nscd 1.10.0
openvpn 1.11.0
portage 1.12.0
postfix 1.13.0
raid 1.11.0
rsync 1.11.0
screen 2.5.0
selinuxutil 1.16.0
ssh 2.3.0
staff 2.3.0
storage 1.10.0
su 1.12.0
sudo 1.9.0
sysadm 2.4.0
sysnetwork 1.13.0
udev 1.14.0
unprivuser 2.3.0
userdomain 4.7.0
usermanage 1.17.0
xdg 1.0.0


#getsebool -a
allow_execheap --> off
allow_execmem --> off
allow_execmod --> off
allow_execstack --> off
allow_httpd_anon_write --> off
allow_httpd_mod_auth_pam --> off
allow_httpd_sys_script_anon_write --> off
allow_httpd_user_script_anon_write --> off
allow_mount_anyfile --> off
allow_polyinstantiation --> off
allow_ptrace --> off
allow_rsync_anon_write --> off
allow_ssh_keysign --> off
allow_user_mysql_connect --> off
allow_user_postgresql_connect --> off
allow_ypbind --> off
console_login --> off
cron_can_relabel --> off
fcron_crond --> off
gentoo_nginx_can_network_connect --> off
gentoo_nginx_can_network_connect_http --> on
gentoo_nginx_enable_http_server --> on
gentoo_nginx_enable_imap_server --> off
gentoo_nginx_enable_pop3_server --> off
gentoo_nginx_enable_smtp_server --> off
gentoo_try_dontaudit --> on
gentoo_wait_requests --> off
global_ssp --> on
httpd_builtin_scripting --> off
httpd_can_network_connect --> off
httpd_can_network_connect_db --> off
httpd_can_network_relay --> off
httpd_can_sendmail --> off
httpd_dbus_avahi --> off
httpd_enable_cgi --> off
httpd_enable_ftp_server --> off
httpd_enable_homedirs --> off
httpd_ssi_exec --> off
httpd_tty_comm --> off
httpd_unified --> off
httpd_use_cifs --> off
httpd_use_gpg --> off
httpd_use_nfs --> off
init_upstart --> off
mail_read_content --> off
mmap_low_allowed --> off
named_write_master_zones --> off
nfs_export_all_ro --> off
nfs_export_all_rw --> off
openvpn_enable_homedirs --> off
portage_use_nfs --> off
rsync_export_all_ro --> on
secure_mode --> on
secure_mode_insmod --> off
secure_mode_policyload --> off
ssh_sysadm_login --> off
use_nfs_home_dirs --> off
use_samba_home_dirs --> off
user_direct_mouse --> off
user_dmesg --> off
user_ping --> off
user_rw_noexattrfile --> off
user_tcp_server --> off
user_ttyfile_stat --> off

#fstab :
/dev/sda1 / ext4 noatime

0 1
/dev/sda3 none swap sw

0 0
proc /proc proc defaults

0 0
tmpfs /tmp tmpfs
defaults,noexec,nosuid,rootcontext=system_u:object_r:tmp_t
0 0
udev /dev tmpfs
rw,rootcontext=system_u:object_r:device_t,seclabel,nosuid,relatime,size=10m,mode=755
0 0
none /selinux selinuxfs noauto

0 0

#mounts :
rootfs on / type rootfs (rw)
/dev/root on / type ext4
(rw,seclabel,noatime,user_xattr,barrier=1,data=ordered)
selinuxfs on /selinux type selinuxfs (rw,relatime)
proc on /proc type proc (rw,relatime)
rc-svcdir on /lib64/rc/init.d type tmpfs
(rw,rootcontext=system_u:object_r:initrc_state_t,seclabel,nosuid,nodev,noexec,relatime,size=1024k,mode=755)
sysfs on /sys type sysfs (rw,seclabel,nosuid,nodev,noexec,relatime)
debugfs on /sys/kernel/debug type debugfs
(rw,nosuid,nodev,noexec,relatime)
udev on /dev type tmpfs
(rw,rootcontext=system_u:object_r:device_t,seclabel,nosuid,relatime,size=10240k,mode=755)
devpts on /dev/pts type devpts
(rw,seclabel,nosuid,noexec,relatime,gid=5,mode=620)
shm on /dev/shm type tmpfs
(rw,rootcontext=system_u:object_r:tmpfs_t,seclabel,nosuid,nodev,noexec,relatime)
tmpfs on /tmp type tmpfs
(rw,noexec,nosuid,rootcontext="system_u:object_r:tmp_t")
binfmt_misc on /proc/sys/fs/binfmt_misc type binfmt_misc
(rw,noexec,nosuid,nodev)

I think something about /sys mount point is missing in my fstab but I'm
unable to find anything about that in the web.

Thanks,
Vincent Brillault


swift at gentoo

Mar 2, 2012, 10:59 AM

Post #2 of 4 (787 views)
Permalink
Re: Unsolved AVCs on a hardened/linux/amd64/selinux [In reply to]

On Fri, Mar 02, 2012 at 11:13:17AM +0100, Vincent Brillault wrote:
> I've installed my first SELinux enhanced Gentoo Hardened a few days
> ago.

Congratulations! And thanks for sharing your experiences.

> A lot of avc appears in the logs and I fear that those would crash the
> server if I try to boot in enforcing mode.

It often helps to first boot in permissive, log on as root, run "id -Z" to
make sure you are in sysadm_t (if not, then enforcing will definitely not
work) and then switch to enforcing mode (setenforce 1) and play around a
bit. That way, you don't need to boot immediately in enforcing (that's the
next step).

> First of all, I think that the current policy lakes a context rules for
> ip6tables, I fixed it by adding the following rule (The context used
> here comes from /var/lib/iptables):
> /var/lib/ip6tables(/.*)? gen_context(system_u:object_r:initrc_tmp_t)

Correct, I'll have this added in rev 5.

> Then, another rule seems to be missing from nginx. I think it's caused
> by a the following line in my configuration: “include
> /etc/nginx/vhosts.d/*.conf;” that result in :
> Mar 2 11:10:47 ***** kernel: [ 968.008780] type=1400
> audit(1330683047.439:55): avc: denied { read } for pid=2257
> comm="nginx" name="vhosts.d" dev="sda1" ino=393764
> scontext=system_u:system_r:nginx_t
> tcontext=system_u:object_r:nginx_conf_t tclass=dir
>
> I added the following rule to resolve this avc:
> allow nginx_t nginx_conf_t:dir read;

Correct. I'll add in a "list_dirs_pattern" for this, which includes the read
privilege. Will be included in rev 5.

> I don't have enough experience to understand the following avcs that
> come after every boot (after I log in) :

I'll give feedback on a few, but it would be nice if we could tackle them
one by one, preferably also a bit later when you could (try to) boot in
enforcing mode.

The problem with debugging in permissive is that the system behavior is
different. An earlier denial in enforcing mode might already prevent other
denials to be reached. And it doesn't mean that that denial is wrong - some
things we notice when enabling SELinux is that many applications have weird
behavior...

> Mar 2 10:54:51 ***** kernel: [ 3.669361] type=1400
> audit(1330682082.668:3): avc: denied { getattr } for pid=736
> comm="mount" name="/" dev="sysfs" ino=1
> scontext=system_u:system_r:mount_t tcontext=system_u:object_r:sysfs_t
> tclass=filesystem
[... snip other getattr on sysfs_t filesystem class ...]

I have these too, not sure yet why they would be needed. I have yet to play
around and see what the difference is in behavior when enabling or
dontauditing this.

I know that recent GLIBCs do a bit more with sysfs almost by default, but I
thought that was about checking the CPU information, not getting attributes
on the file system...

> Mar 2 10:54:51 ***** kernel: [ 7.767982] type=1400
> audit(1330682087.198:6): avc: denied { setsched } for pid=1010
> comm="mount" scontext=system_u:system_r:mount_t
> tcontext=system_u:system_r:kernel_t tclass=process

Hmm, don't have these here.

> 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).

> 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.

> 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.

> Mar 2 10:54:51 ***** kernel: [ 8.719682] type=1400
> audit(1330682088.150:11): avc: denied { getattr } for pid=1175
> comm="fuser" path="socket:[1859]" dev="sockfs" ino=1859
> scontext=system_u:system_r:initrc_t tcontext=system_u:system_r:udev_t
> tclass=unix_stream_socket

Probably /etc/init.d/bootmisc (as it is the only feasible init script that
calls fuser) that finds stuff in /var/run and wants to clean them.

[... snip many other denials ...]
> I think something about /sys mount point is missing in my fstab but I'm
> unable to find anything about that in the web.

Don't worry, /sys is mounted by default even if you don't define it in your
/etc/fstab.

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

Wkr,
Sven Vermeulen


gentoo at lerya

Mar 3, 2012, 5:56 AM

Post #3 of 4 (792 views)
Permalink
Re: Unsolved AVCs on a hardened/linux/amd64/selinux [In reply to]

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


gentoo at lerya

Mar 7, 2012, 4:24 AM

Post #4 of 4 (789 views)
Permalink
Re: Unsolved AVCs on a hardened/linux/amd64/selinux [In reply to]

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

As promised, here are some other avcs :
(Those appears in enforcing mode, after booting in permissive mode)

---

The denies on search or gettattr on "/sys/fs/selinux" that appears on a
lot of different actions (run_init, sudo, ssh ..) doesn't seem to have a
negative impact. (I didn't check in details but nothing appears in basic
tests).

---

I have another group of denies that don't seem to have a direct impact:
Whenever I manipulate iptables (run_init /etc/etc.init.d/iptables
restart, iptables-save, iptables -vL ...). Those denies don't prevent
iptables from saving, restoring or modifying its rules (on the filter or
nat tables at least)

Example:
'''
type=AVC msg=audit(1331040320.724:7829): avc: denied { getattr } for
pid=4095 comm="iptables-restor" name="/" dev="proc" ino=1
scontext=system_u:system_r:iptables_t
tcontext=system_u:object_r:proc_t tclass=filesystem
type=SYSCALL msg=audit(1331040320.724:7829): arch=c000003e syscall=137
success=no exit=-13 a0=2f0ed1a8353 a1=3edf4358080 a2=3edf4357ff0
a3=3edf4358110 items=1 ppid=4088 pid=4095 auid=1000 uid=0 gid=0 euid=0
suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts4 ses=27
comm="iptables-restor" exe="/sbin/xtables-multi"
subj=system_u:system_r:iptables_t key=(null)
type=CWD msg=audit(1331040320.724:7829): cwd="/"
type=PATH msg=audit(1331040320.724:7829): item=0
name="/proc/net/ip_tables_names" inode=4026532099 dev=00:03 mode=0100440
ouid=0 ogid=10 rdev=00:00 obj=system_u:object_r:proc_net_t
'''

From what I understand of the code, this test is used to determine if
the modules needed for iptables are load or not in the function
xtables_load_ko in iptables/xtables.c which is called by
iptables-(restore|save) (but the return value is dropped). If we compare
verbose audits of permissive mode VS enforcing mode, we ca see a new
syscall that appears in enforcing mode only (I didn't used really
verbose audits to their might be other impacts) :

'''
type=SYSCALL msg=audit(1331111858.712:27814): arch=c000003e syscall=2
success=no exit=-2 a0=3368a74f203 a1=0 a2=1 a3=3368a1bdf70 items=1
ppid=2763 pid=3547 auid=1000 uid=0 gid=0 euid=0 suid=0 fsuid=0
egid=0 sgid=0 fsgid=0 tty=pts1 ses=9 comm="iptables-save"
exe="/sbin/xtables-multi" subj=staff_u:sysadm_r:iptables_t key=(null)
type=PATH msg=audit(1331111858.712:27814): item=0
name="/proc/sys/kernel/modprobe"
'''

----

During the boot in permissive mode:

If unicode is set to "YES" in rc.conf:
Mar 6 14:36:45 lerya kernel: [ 12.289270] type=1400
audit(1331041002.720:15): avc: denied { add_name } for pid=1459
comm="runscript.sh" name="unicode" scontext=system_u:system_r:initrc_t
tcontext=system_u:object_r:lib_t tclass=dir
Mar 6 14:36:45 lerya kernel: [ 12.289302] type=1400
audit(1331041002.720:16): avc: denied { create } for pid=1459
comm="runscript.sh" name="unicode" scontext=system_u:system_r:initrc_t
tcontext=system_u:object_r:lib_t tclass=file

It's probably cause by /etc/init.d/(keymaps|termencoding). As I don't
need those two scripts I disactivated these two. After the first reboot,
these "create" denies disappeared and after the second one the "remove"
denies from bootmisc also disappeared (They creates those files and
don't purge them after the reboot).

--

I finally try to reboot in enforcing mode (after suppresing manually the
wirting test on /var/run done by bootmisc). The system more or less
correctly booted (in disorder):

- a lot of sysfs_t denies (I ignored them)
- fuser related denies (idem)
- iptables "proc" denies (idem)
- Asterisk denies (same as in the last email)
- sysctl denies (the sames as for Tomas Dobrovolny)
- Some new stuff:

*

kernel: [ 2.513633] type=1400 audit(1331043603.512:4): avc: denied
{ search } for pid=1 comm="init" name="proc" dev="sda1" ino=131438
scontext=system_u:system_r:init_t tcontext=system_u:object_r:mnt_t
tclass=dir
Present 2 times, I don't know the impact of this yet

*

kernel: [ 3.902691] type=1400 audit(1331043604.901:9): avc: denied
{ search } for pid=744 comm="mount" name="/" dev="cgroup" ino=1674
scontext=system_u:system_r:kernel_t
tcontext=system_u:object_r:unlabeled_t tclass=dir
(Appears each boot, on variable ino, sometime 1 time, sometime 4 times)
(Each ino seems to be some directory in /sys/fs/cgroup/)

Why do I have "unlabeled_t" dirs ?
After the boot, all the directories in /sys/fs/cgroup/ are labbeled and
mounted, so it's perhaps only some bad ordering of operation during the
boot.

Seems related to https://bugzilla.redhat.com/show_bug.cgi?id=700538 (I'm
running on kernel 3.2.2-hardened-r1).

*

Chmod on /tmp:

type=AVC msg=audit(1331115836.150:76): avc: denied { setattr } for
pid=2121 comm="chmod" name="/" dev="tmpfs" ino=3136
scontext=system_u:system_r:initrc_t tcontext=system_u:object_r:tmp_t
tclass=dir
type=SYSCALL msg=audit(1331115836.150:76): arch=c000003e syscall=268
success=no exit=-13 a0=ffffffffffffff9c a1=35c5218e70 a2=3ff a3=0
items=1 ppid=1646 pid=2121 auid=4294967295 uid=0 gid=0 euid=0 suid=0
fsuid=0 egid=0 sgid=0 fsgid=0 tty=tty1 ses=4294967295 comm="chmod"
exe="/bin/chmod" subj=system_u:system_r:initrc_t key=(null)
type=CWD msg=audit(1331115836.150:76): cwd="/"
type=PATH msg=audit(1331115836.150:76): item=0 name="/tmp" inode=3136
dev=00:19 mode=041777 ouid=0 ogid=0 rdev=00:00
obj=system_u:object_r:tmp_t

I think it's bootmisc again, but no proof about that.

*

kernel: [ 14.256338] type=1400 audit(1331043615.680:69): avc: denied
{ sys_admin } for pid=2127 comm="ip" capability=21
scontext=system_u:system_r:ifconfig_t
tcontext=system_u:system_r:ifconfig_t tclass=capability

I think this is related to (taken from the rc.log logs):
"Cannot flush routing cache"
No ideas on the real consequences...

---

Is there a good spot to find avc already solved ? (I hope that most of
the avc here are new and not some well-known bugs. I tried to search
information on each of them, with only small success)

Do you have anything new on the sysctl denies ?

Sincerely yours,
Vincent Brillault

Gentoo hardened RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.