Re: RHEL 7 consoletype_exec interface issue
by Douglas Brown
Hi,
In RHEL 7 when using the userdom_unpriv_user_template interface to create a new role, it in turn uses the consoletype_exec interface; but when I attempt to insert a policy compiled with this, it says the type consoletype_exec_t doesn’t exist.
N.B. This works on RHEL 6.
Thanks,
Doug
7 years, 1 month
Cannot find rpm
by mark
Hi, folks,
We're working on several new CentOS 7 systems, moving users from
CentOS 6. Now, the users have had some *sigh* custom stuff, like their
own version of Perl (please do *not* ask, and I would *love* to get
them off it, but....)
Anyway, in the directory it's in, I did a semanage fcontext -e
/usr/bin, and now I'm seeing errors in the log of selinux complaining
it can't find the rpm (because there's not one for this).
What's the correct way to deal with this - different labelling, a local
policy, or ?
mark
7 years, 10 months
Training for Writing SELinux Policy
by Fong Vang
Which training classes are best for hands-on experience writing SELinux policies? Any recommendations? Preferably offsite for a week.
7 years, 11 months
CentOS 6.8 alsactl AVCs
by Robert Nichols
In a CentOS 6.8 host with a CentOS 6.8 QEMU-KVM guest, I have a USB
sound device that I assign to the guest. Since the update to CentOS 6.8,
whenever I assign the USB host device to the guest or return it to the
host I get AVC deniala for alsactl writing to the /var/lock directory:
type=AVC msg=audit(1464239503.474:168): avc: denied { write } for
pid=6462 comm="alsactl" name="lock" dev="dm-1" ino=1310721
scontext=system_u:system_r:alsa_t:s0-s0:c0.c1023
tcontext=system_u:object_r:var_lock_t:s0 tclass=dir permissive=0
type=SYSCALL msg=audit(1464239503.474:168): arch=x86_64 syscall=open
success=no exit=EACCES a0=4122a3 a1=c2 a2=1a4 a3=7fff7e7950a0 items=0
ppid=6325 pid=6462 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0
egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm=alsactl
exe=/sbin/alsactl subj=system_u:system_r:alsa_t:s0-s0:c0.c1023 key=(null)
I don't see any reason to deny this, so I have run the recommended
audit2allow steps. Unless someone tells me otherwise, I'll report this
as a bug in the policy.
selinux-policy-3.7.19-292.el6.noarch
selinux-policy-targeted-3.7.19-292.el6.noarch
--
Bob Nichols "NOSPAM" is really part of my email address.
Do NOT delete it.
7 years, 11 months
Possible bug: file context is not defined
by mark
CentOS 7, updated.
selinux_policy: 3.13.1-60
selinux_policy_targeted: 3.13.1-60
python: SELinux is preventing <blah_blah_stupid user path> from getattr
access on the chr_file /dev/ipmi0.#012#012***** Plugin restorecon (90.5
confidence) suggests ************************#012#012If you want to fix
the label. #012/dev/ipmi0 default label should be ipmi_device_
So I tried:
semanage fcontext -m -t ipmi_device_t /dev/ipmi0
ValueError: File context for /dev/ipmi0 is not defined
mark
7 years, 11 months
xinetd and su/runuser and dbus
by Troels Arvin
Hello,
Environment:
RHEL 7.2 with all the latest fixes.
The server has the Check_MK agent (check-mk-agent-1.2.6p16-3.el7.x86_64
from EPEL) installed, and the mk_postgres module has been activated by
symlinking /usr/share/check-mk-agent/available-plugins/mk_postgres to
/usr/share/check-mk-agent/plugins/mk_postgres
The agent plugin's code may be viewed here:
http://git.mathias-kettner.de/git/?p=check_mk.git;a=blob;f=agents/plugins/
mk_postgres;h=8333eee316a99e634394aee4f3048b6becc56d69;hb=c33010ba2d24c8b81c4e6221f3cd61bade7e7d9e
PostgreSQL version: rh-postgresql94-postgresql 9.4.6-1.el7.x86_64 (from
RHEL 7's software collections).
Trouble: The Check_MK agent reponse becomes very slow when the
mk_postgres agent plugin is activated -- to the extend that checks time
out, causing monitoring alerts and missing monitoring data.
Meanwhile, in /var/log/audit/audit.log:
type=USER_AVC msg=audit(1462018794.424:153): pid=704 uid=81
auid=4294967295 ses=4294967295 subj=system_u:system_r:system_dbusd_t:s0-
s0:c0.c1023 msg='avc: denied { send_msg } for msgtype=method_return
dest=:1.19 spid=925 tpid=2851
scontext=system_u:system_r:systemd_logind_t:s0
tcontext=system_u:system_r:inetd_child_t:s0-s0:c0.c1023 tclass=dbus
exe="/usr/bin/dbus-daemon" sauid=81 hostname=? addr=? terminal=?'
The AVC denials pop up when the mk_postgres agent plugin performs a "su"
to "postgres". Changing the script to use "runuser" instead of "su" does
not help.
I've found two different ways to fix this; the latter seems best:
1. Stop the dbus.service and dbus.socket services. But this results in a
subsequent flood of messages like:
Apr 29 21:48:12 hostname su: pam_systemd(su-l:session): Failed to connect
to system bus: Connection refused
2. Add the following SELinux module:
---------------------------------------
module inetd_dbus 1.0;
require {
type systemd_logind_t;
type inetd_child_t;
class dbus send_msg;
}
#============= systemd_logind_t ==============
allow systemd_logind_t inetd_child_t:dbus send_msg;
---------------------------------------
I wonder if the above SELinux module could become part of the main
SELinux
policy? If so, should I open a Bugzilla request for xinetd, dbus, or
SELinux?
--
Regards,
Troels Arvin
7 years, 11 months
