I want to have a script that acts slightly differently depending on
whether SELinux is being used or not. What is the best way to do it?
My initial attempts to use "-e /etc/security/selinux" or "-e
/selinux/enforce" all create log messages:
audit(1079689937.170:0): avc: denied { getattr } for pid=2662
exe=/bin/bash path=/etc/security/selinux dev=hda2 ino=3712021
scontext=aleksey:staff_r:staff_t
tcontext=system_u:object_r:policy_config_t tclass=dir
audit(1079690744.526:0): avc: denied { getattr } for pid=3577
exe=/bin/bash path=/selinux/enforce dev= ino=4
scontext=aleksey:staff_r:staff_t tcontext=system_u:object_r:security_t
tclass=file
--
Aleksey Nogin
Home Page: http://nogin.org/
E-Mail: nogin(a)cs.caltech.edu (office), aleksey(a)nogin.org (personal)
Office: Jorgensen 70, tel: (626) 395-2907
Not sure where these come from (possibly it's because of my using the
vnc module in X). Safe to dontaudit?
audit(1079686139.241:0): avc: denied { getattr } for pid=9439
exe=/usr/X11R6/bin/XFree86 path=/dev/urandom dev=hda2 ino=2689265
scontext=system_u:system_r:xdm_xserver_t
tcontext=system_u:object_r:urandom_device_t tclass=chr_file
audit(1079686139.241:0): avc: denied { ioctl } for pid=9439
exe=/usr/X11R6/bin/XFree86 path=/dev/urandom dev=hda2 ino=2689265
scontext=system_u:system_r:xdm_xserver_t
tcontext=system_u:object_r:urandom_device_t tclass=chr_file
--
Aleksey Nogin
Home Page: http://nogin.org/
E-Mail: nogin(a)cs.caltech.edu (office), aleksey(a)nogin.org (personal)
Office: Jorgensen 70, tel: (626) 395-2907
I ran "... | mail -s ... aleksey" while running under sysadm_r and I got:
audit(1079685757.727:0): avc: denied { read } for pid=9687
exe=/usr/sbin/sendmail.sendmail name=self dev= ino=2
scontext=aleksey:sysadm_r:sysadm_mail_t
tcontext=system_u:object_r:proc_t tclass=lnk_file
audit(1079685757.727:0): avc: denied { search } for pid=9687
exe=/usr/sbin/sendmail.sendmail name=9687 dev= ino=634847234
scontext=aleksey:sysadm_r:sysadm_mail_t
tcontext=aleksey:sysadm_r:sysadm_mail_t tclass=dir
audit(1079685757.751:0): avc: denied { dac_override } for pid=9688
exe=/usr/sbin/sendmail.sendmail capability=1
scontext=system_u:system_r:sendmail_t
tcontext=system_u:system_r:sendmail_t tclass=capability
The first one is probably an issue with how the kernel manages /proc -
/proc/self IMHO should not be system_u:object_r:proc_t.
--
Aleksey Nogin
Home Page: http://nogin.org/
E-Mail: nogin(a)cs.caltech.edu (office), aleksey(a)nogin.org (personal)
Office: Jorgensen 70, tel: (626) 395-2907
When running hostname (or hostname -s) to _get_ (not set) the hostname
as a "staff" user - under sysadm_r:
audit(1079685457.360:0): avc: denied { read } for pid=9499
exe=/bin/hostname name=resolv.conf dev=hda2 ino=229950
scontext=aleksey:sysadm_r:hostname_t
tcontext=system_u:object_r:net_conf_t tclass=file
audit(1079685457.361:0): avc: denied { getattr } for pid=9499
exe=/bin/hostname path=/etc/resolv.conf dev=hda2 ino=229950
scontext=aleksey:sysadm_r:hostname_t
tcontext=system_u:object_r:net_conf_t tclass=file
audit(1079685457.361:0): avc: denied { create } for pid=9499
exe=/bin/hostname scontext=aleksey:sysadm_r:hostname_t
tcontext=aleksey:sysadm_r:hostname_t tclass=unix_stream_socket
audit(1079685457.361:0): avc: denied { connect } for pid=9499
exe=/bin/hostname scontext=aleksey:sysadm_r:hostname_t
tcontext=aleksey:sysadm_r:hostname_t tclass=unix_stream_socket
The socket ones are coming from, I believe, trying to access
/var/run/nscd/socket that does not exist (nscd was never used on this
machine).
--
Aleksey Nogin
Home Page: http://nogin.org/
E-Mail: nogin(a)cs.caltech.edu (office), aleksey(a)nogin.org (personal)
Office: Jorgensen 70, tel: (626) 395-2907
Contrast the following two:
% su -c id
Password:
uid=0(root) gid=0(root)
groups=0(root),1(bin),2(daemon),3(sys),4(adm),6(disk),10(wheel)
context=root:sysadm_r:sysadm_t
% sudo id
Password:
uid=0(root) gid=0(root)
groups=0(root),1(bin),2(daemon),3(sys),4(adm),6(disk),10(wheel)
context=user_u:user_r:user_t
How do I change my local policy so have sudo grant the same sysadm
permissions as su does? Is it possible to make it tunable? Or is this
something that is very dangerous and should not be done? Thanks!
--
Aleksey Nogin
Home Page: http://nogin.org/
E-Mail: nogin(a)cs.caltech.edu (office), aleksey(a)nogin.org (personal)
Office: Jorgensen 70, tel: (626) 395-2907
If I want syslogd to log to a tty, what is the "proper" way of allowing it?
Should I augment the local file contexts to set /dev/tty10 to be
var_log_t? Or should I augment the local policies to allow syslogd_t
processes more access? Or should I do something else?
Thanks!
--
Aleksey Nogin
Home Page: http://nogin.org/
E-Mail: nogin(a)cs.caltech.edu (office), aleksey(a)nogin.org (personal)
Office: Jorgensen 70, tel: (626) 395-2907