VASD policy
by Vadym Chepkov
Hi,
I noticed just one vasd related entry found it's way into SELinux policy:
# grep vasd ./serefpolicy-3.7.19/policy/modules/system/authlogin.fc
/var/opt/quest/vas/vasd(/.*)? gen_context(system_u:object_r:var_auth_t,s0)
vasd is part of Quest Auth Services and I wonder if somebody already has a
policy defined for it or I have to start from scratch. Quest suggested to
disable SELinux, of cause.
Thanks,
Vadym
9 years, 8 months
Puppet 3 troubles on F19
by Robin Lee Powell
So I just upgraded to F19, which means I get Puppet 3 (yay!).
I'm running with unconfined disabled.
Unfortunately, it looks like the policy hasn't been updated for
puppet in quite a while. For example, from
serefpolicy-contrib-3.12.1/puppet.fc (which I got from
selinux-policy-3.12.1-66.fc19.src.rpm ) I see:
/etc/rc\.d/init\.d/puppet -- gen_context(system_u:object_r:puppet_initrc_exec_t,s0)
/etc/rc\.d/init\.d/puppetmaster -- gen_context(system_u:object_r:puppetmaster_initrc_exec_t,s0)
/usr/sbin/puppetca -- gen_context(system_u:object_r:puppetca_exec_t,s0)
/usr/sbin/puppetd -- gen_context(system_u:object_r:puppet_exec_t,s0)
/usr/sbin/puppetmasterd -- gen_context(system_u:object_r:puppetmaster_exec_t,s0)
Not a one of those files exists anymore.
This means that things go quite poorly. For example, "sudo
systemctl restart puppetmaster.service" gets me:
type=AVC msg=audit(07/29/2013 22:07:49.780:2300368) : avc: denied { open } for pid=28302 comm=ruby-mri path=/var/lib/puppet/ssl/ca/ca_key.pem dev="dm-1" ino=401335 scontext=system_u:system_r:initrc_t:s0 tcontext=system_u:object_r:puppet_var_lib_t:s0 tclass=file
type=AVC msg=audit(07/29/2013 22:07:49.780:2300368) : avc: denied { read } for pid=28302 comm=ruby-mri name=ca_key.pem dev="dm-1" ino=401335 scontext=system_u:system_r:initrc_t:s0 tcontext=system_u:object_r:puppet_var_lib_t:s0 tclass=file
----
type=AVC msg=audit(07/29/2013 22:07:49.780:2300369) : avc: denied { ioctl } for pid=28302 comm=ruby-mri path=/var/lib/puppet/ssl/ca/ca_key.pem dev="dm-1" ino=401335 scontext=system_u:system_r:initrc_t:s0 tcontext=system_u:object_r:puppet_var_lib_t:s0 tclass=file
----
type=AVC msg=audit(07/29/2013 22:07:49.966:2300370) : avc: denied { create } for pid=28307 comm=ruby-mri name=master.pid scontext=system_u:system_r:initrc_t:s0 tcontext=system_u:object_r:puppet_var_run_t:s0 tclass=file
type=AVC msg=audit(07/29/2013 22:07:49.966:2300370) : avc: denied { add_name } for pid=28307 comm=ruby-mri name=master.pid scontext=system_u:system_r:initrc_t:s0 tcontext=system_u:object_r:puppet_var_run_t:s0 tclass=dir
----
type=SOCKADDR msg=audit(07/29/2013 22:07:49.982:2300371) : saddr=inet host:0.0.0.0 serv:8140
type=AVC msg=audit(07/29/2013 22:07:49.982:2300371) : avc: denied { name_bind } for pid=28307 comm=ruby-mri src=8140 scontext=system_u:system_r:initrc_t:s0 tcontext=system_u:object_r:puppet_port_t:s0 tclass=tcp_socket
because it's running as initrc_t instead of puppetmaster_t:
system_u:system_r:initrc_t:s0 puppet 28307 0.0 0.5 309556 43464 ? Ssl 22:07 0:00 /usr/bin/ruby-mri /usr/bin/puppet master
My knowledge of puppet is considerable, but my selinux is only
decent. In particular, the Right Thing here is for the systemd
launch of puppetmaster to put things into the right context, but
I've no idea how to accomplish that.
Is there someone I can work with to fix up this policy?
-Robin
10 years, 1 month
Why do matchpathcon and restorecon ignore the user context by default?
by Bram Mertens
Hi,
I have just lost several hours trying to figure out why I was unable
to deploy a file from a configuration channel in our satellite server
to a RHEL6 box while it deployed perfectly to a RHEL5 box.
I finally tracked it down to the fact that the user context was set to
unconfined_u while the rest of the context was set correctly.
On RHEL5 rhncfg-client get worked flawlessly and deployed the file
with a *different* user context (system_u) without complaining.
On RHEL6 chncfg-client crashed complaining about the SElinux context -
which differed only in the user context.
Here's what I found (I also posted this as a follow up on the
rhn-satellite mailing list):
I see some very strange behaviour of SELinux on this RHEL6 box.
on RHEL5 the following works as expected:
The default SELinux security context for /etc/sssd/sssd.conf is:
[mertensb@testadintegration01 ~]$ sudo /usr/sbin/matchpathcon
/etc/sssd/sssd.conf
/etc/sssd/sssd.conf system_u:object_r:etc_t
Which is also what is currently applied:
[mertensb@testadintegration01 ~]$ sudo ls -lZ /etc/sssd/sssd.conf
-rw------- root root system_u:object_r:etc_t /etc/sssd/sssd.conf
So matchpathcon is able to verify the context.
[mertensb@testadintegration01 ~]$ sudo /usr/sbin/matchpathcon -V
/etc/sssd/sssd.conf
/etc/sssd/sssd.conf verified.
Testing a randomn other file to verify that matchpathcon works:
[mertensb@testadintegration01 ~]$ touch /tmp/proftpd
[mertensb@testadintegration01 ~]$ sudo ls -lZ /tmp/proftpd
-rw-rw-r-- mertensb mertensb user_u:object_r:tmp_t /tmp/proftpd
[mertensb@testadintegration01 ~]$ sudo mv /tmp/proftpd /etc/cron.monthly/proftpd
[mertensb@testadintegration01 ~]$ sudo ls -lZ /etc/cron.monthly/proftpd
-rw-rw-r-- mertensb mertensb user_u:object_r:tmp_t
/etc/cron.monthly/proftpd
[mertensb@testadintegration01 ~]$ sudo /usr/sbin/matchpathcon
/etc/cron.monthly/proftpd
/etc/cron.monthly/proftpd system_u:object_r:ftpd_exec_t
[mertensb@testadintegration01 ~]$ sudo /usr/sbin/matchpathcon -V
/etc/cron.monthly/proftpd
/etc/cron.monthly/proftpd has context user_u:object_r:tmp_t, should be
system_u:object_r:ftpd_exec_t
But on the RHEL6 machine I get:
[mertensb@defrltot002 ~]$ sudo ls -lZ /etc/sssd/sssd.conf
-rw-------. root root unconfined_u:object_r:etc_t:s0 /etc/sssd/sssd.conf
[mertensb@defrltot002 ~]$ sudo /usr/sbin/matchpathcon /etc/sssd/sssd.conf
/etc/sssd/sssd.conf system_u:object_r:etc_t:s0
[mertensb@defrltot002 ~]$ sudo /usr/sbin/matchpathcon -V /etc/sssd/sssd.conf
/etc/sssd/sssd.conf verified.
Repeating my test of matchpathcon:
[mertensb@defrltot002 ~]$ touch /tmp/proftpd
[mertensb@defrltot002 ~]$ sudo mv /tmp/proftpd /etc/cron.monthly/proftpd
[mertensb@defrltot002 ~]$ sudo ls -lZ /etc/cron.monthly/proftpd
-rw-r--r--. mertensb ISOP unconfined_u:object_r:user_
tmp_t:s0
/etc/cron.monthly/proftpd
[mertensb@defrltot002 ~]$ sudo /usr/sbin/matchpathcon /etc/cron.monthly/proftpd
/etc/cron.monthly/proftpd system_u:object_r:ftpd_exec_t:s0
[mertensb@defrltot002 ~]$ sudo /usr/sbin/matchpathcon -V
/etc/cron.monthly/proftpd
/etc/cron.monthly/proftpd has context
unconfined_u:object_r:user_tmp_t:s0, should be
system_u:object_r:ftpd_exec_t:s0
Both have the same sssd SELinux policy loaded:
RHEL5:
[mertensb@testadintegration01 ~]$ sudo /usr/sbin/semodule -l|grep sssd
sssd 1.0.2
RHEL6:
[mertensb@defrltot002 ~]$ sudo /usr/sbin/semodule -l|grep sssd
sssd 1.0.2
Digging further I found out that if only the user context is different
matchpathcon returns OK.
See http://manpages.ubuntu.com/manpages/karmic/man3/matchpathcon.3.html
I also found a post on this list indicating that restorecon has a
forece option to make it set the user context which it doesn't do by
default: http://fedora.12.x6.nabble.com/restorecon-isn-t-restoring-what-matchpathc...
So why isn't the user context set/reset by default?
After all it clearly leaves the system in a broken state.
And why doesn't matchpathcon have a similar force option to make it
check the entire context?
Thanks in advance.
Bram Mertens
10 years, 2 months
Unable to modify a file in enforcing mode, but no denials seen even after semodule -DB
by Radha Venkatesh (radvenka)
We have a strange issue showing up in our system. We are trying to modify a configuration file - we are unable to in enforcing mode but are able to in permissive mode. There are no denials seen.
We have run semodule -DB, to get to the hidden denials, but to no avail.
Could you give us some pointers on how to get to the bottom of this?
Thanks,
Radha.
10 years, 2 months
RE: Unable to modify a file in enforcing mode, but no denials seen even after semodule -DB
by Radha Venkatesh (radvenka)
Any input on the below question?
From: Radha Venkatesh (radvenka)
Sent: Tuesday, July 30, 2013 4:12 PM
To: fedora-selinux-list(a)redhat.com; selinux(a)lists.fedoraproject.org
Cc: ipc-selinux-dev(mailer list); Prakash Mishra -X (prakasmi - INFOSYS TECHNOLOGIES LIMITED at Cisco)
Subject: Unable to modify a file in enforcing mode, but no denials seen even after semodule -DB
We have a strange issue showing up in our system. We are trying to modify a configuration file - we are unable to in enforcing mode but are able to in permissive mode. There are no denials seen.
We have run semodule -DB, to get to the hidden denials, but to no avail.
Could you give us some pointers on how to get to the bottom of this?
Thanks,
Radha.
10 years, 2 months
Bootup error with Selinux +F15
by magina antimage
Hi,
i have tried disabling SElinux ,because i didnt had selinux module
enabled in my kernel.
i have tried changing /etc/selinux/config:
from SELINUX=permissive to SELINUX=disabled
but still i get error
"Failed to load SELinux policy." during bootup
i have referred to "https://bugzilla.redhat.com/show_bug.cgi?id=692573 "
and tried to solve this problem, but no positive results
also sometimes i get I/O errors on my hard disk (during boot) after
one or two boots .
i am not sure whether its because of SElinux or not,but while
searching this I/O error i came across few cases where these I/O
errors were because of SElinux policies.
other details:
arch:x86
selinux version:libselinux-2.0.99-4.fc15.i686
10 years, 2 months
AVC for modprobe loading ebtables
by Andy Ruch
Hello,
I'm implementing a custom policy based on ref policy for RHEL 6.3. I'm receiving the AVC below when the system boots. Should I allow this? I was able to find this related posting (https://bugzilla.redhat.com/show_bug.cgi?id=431562) but it was for an old version of iptables. Maybe ebtables has the same type of bug?
type=PATH msg=audit(07/12/2013 13:15:40.172:185) : item=1 name=(null) inode=4912 dev=08:02 mode=file,755 ouid=root ogid=root rdev=00:00 obj=system_u:object_r:ld_so_t:s0
type=PATH msg=audit(07/12/2013 13:15:40.172:185) : item=0 name=/sbin/modprobe inode=12835 dev=08:02 mode=file,755 ouid=root ogid=root rdev=00:00 obj=system_u:object_r:insmod_exec_t:s0
type=CWD msg=audit(07/12/2013 13:15:40.172:185) : cwd=/
type=EXECVE msg=audit(07/12/2013 13:15:40.172:185) : argc=2 a0=/sbin/modprobe a1=ebtables
type=SYSCALL msg=audit(07/12/2013 13:15:40.172:185) : arch=x86_64 syscall=execve success=yes exit=0 a0=1078740 a1=7fffb5126460 a2=7fffb51266b0 a3=7fffb51261e0 items=2 ppid=2109 pid=2110 auid=unset uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=(none) ses=unset comm=modprobe exe=/sbin/modprobe subj=system_u:system_r:insmod_t:s0-s0:c0.c1023 key=modules
type=AVC msg=audit(07/12/2013 13:15:40.172:185) : avc: denied { read write } for pid=2110 comm=modprobe path=socket:[16196] dev=sockfs ino=16196 scontext=system_u:system_r:insmod_t:s0-s0:c0.c1023 tcontext=system_u:system_r:iptables_t:s0-s0:c0.c1023 tclass=rawip_socket
Thanks,
Andy Ruch
10 years, 2 months
selinux blocking ssh login in f20 cloud image
by Matthew Miller
So, I haven't changed anything significant in how the F20 cloud images are
generated from how the F19 ones were. But now, when I try to log into one
after booting, cloud-init runs and appears to configure everything, but
sshing in gives
/bin/bash: Permission denied
In the logs:
Jul 19 14:56:50 localhost sshd[621]: ssh_selinux_change_context: setcon system_u:system_r:sshd_net_t:s0 from system_u:system_r:kernel_t:s0 failed with Permission denied [preauth]
Jul 19 14:56:51 localhost sshd[621]: Accepted publickey for fedora from 192.168.77.1 port 40992 ssh2
Jul 19 14:56:51 localhost systemd: Starting user-1000.slice.
Jul 19 14:56:51 localhost systemd: Created slice user-1000.slice.
Jul 19 14:56:51 localhost systemd: Starting User Manager for 1000...
Jul 19 14:56:51 localhost systemd: Failed at step PAM spawning /usr/lib/systemd/systemd: Operation not permitted
Jul 19 14:56:51 localhost systemd: Starting Session 1 of user fedora.
Jul 19 14:56:51 localhost systemd-logind: New session 1 of user fedora.
Jul 19 14:56:51 localhost systemd: Started Session 1 of user fedora.
Jul 19 14:56:51 localhost systemd: Started User Manager for 1000.
Jul 19 14:56:51 localhost sshd[621]: pam_unix(sshd:session): session opened for user fedora by (uid=0)
Jul 19 14:56:51 localhost sshd[627]: ssh_selinux_copy_context: setcon failed with Permission denied
Jul 19 14:56:51 localhost sshd[627]: Received disconnect from 192.168.77.1: 11: disconnected by user
Jul 19 14:56:51 localhost sshd[621]: pam_unix(sshd:session): session closed for user fedora
Jul 19 14:56:51 localhost systemd-logind: Removed session 1.
Jul 19 14:56:51 localhost systemd: Stopping user-1000.slice.
Jul 19 14:56:51 localhost systemd: Removed slice user-1000.slice
Is this a policy bug? Something new which is failing on image build?
Something else?
--
Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ <mattdm(a)fedoraproject.org>
10 years, 2 months
Easter Egg?
by Frank Murphy
Rawhide(F20)
remote command:
sealert -a /var/log/audit/audit.log | mailx -s "Selinux AVC
Analysis" user
From: root
To: user(a)someisp.com
Subject: Selinux AVC Analysis
Date: Sun, 21 Jul 2013 11:16:06 +0100
Dan
Dan
Dan
Dan
Dan
Dan
Dan
Dan
Dan
Dan
Dan
found 2 alerts in /var/log/audit/audit.log
<snipped/>
--
Regards,
Frank "When in doubt PANIC!"
I check for new mail app. 20min
www.frankly3d.com
10 years, 2 months
