The sealert below does not tell me exactly which dir that the shell tried to access. I have run the suggested commands (below) but they did not do any good. The alerts keep popping up.
SELinux is preventing /usr/bin/sh from read access on the directory .
***** Plugin catchall (100. confidence) suggests **************************
If you believe that sh should be allowed read access on the directory by default. Then you should report this as a bug. You can generate a local policy module to allow this access. Do allow this access for now by executing: # grep sa1 /var/log/audit/audit.log | audit2allow -M mypol # semodule -i mypol.pp
Additional Information: Source Context system_u:system_r:sysstat_t:s0-s0:c0.c1023 Target Context system_u:object_r:admin_home_t:s0 Target Objects [ dir ] Source sa1 Source Path /usr/bin/sh Port <Unknown> Host localhost.localdomain Source RPM Packages sh-20120801-23.fc20.x86_64 Target RPM Packages Policy RPM selinux-policy-3.12.1-197.fc20.noarch Selinux Enabled True Policy Type targeted Enforcing Mode Enforcing Host Name localhost.localdomain Platform Linux localhost.localdomain 3.11.10-301.fc20.x86_64 #1 SMP Thu Dec 5 14:01:17 UTC 2013 x86_64 x86_64 Alert Count 4 First Seen 2015-07-18 18:20:02 MDT Last Seen 2015-07-18 18:50:01 MDT Local ID d59f7aa5-d595-46be-8186-412acb6133bf
Raw Audit Messages type=AVC msg=audit(1437267001.953:644): avc: denied { read } for pid=6476 comm="sa1" name="root" dev="sda3" ino=47972353 scontext=system_u:system_r:sysstat_t:s0-s0:c0.c1023 tcontext=system_u:object_r:admin_home_t:s0 tclass=dir
type=SYSCALL msg=audit(1437267001.953:644): arch=x86_64 syscall=openat success=no exit=EACCES a0=ffffffffffffff9c a1=4fcb93 a2=80800 a3=0 items=0 ppid=6474 pid=6476 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 ses=22 tty=(none) comm=sa1 exe=/usr/bin/sh subj=system_u:system_r:sysstat_t:s0-s0:c0.c1023 key=(null)
Hash: sa1,sysstat_t,admin_home_t,dir,read
On 07/19/15 09:00, jd1008 wrote:
The sealert below does not tell me exactly which dir that the shell tried to access. I have run the suggested commands (below) but they did not do any good. The alerts keep popping up.
SELinux is preventing /usr/bin/sh from read access on the directory .
***** Plugin catchall (100. confidence) suggests **************************
If you believe that sh should be allowed read access on the directory by default. Then you should report this as a bug. You can generate a local policy module to allow this access. Do allow this access for now by executing: # grep sa1 /var/log/audit/audit.log | audit2allow -M mypol # semodule -i mypol.pp
Additional Information: Source Context system_u:system_r:sysstat_t:s0-s0:c0.c1023 Target Context system_u:object_r:admin_home_t:s0 Target Objects [ dir ] Source sa1 Source Path /usr/bin/sh Port <Unknown> Host localhost.localdomain Source RPM Packages sh-20120801-23.fc20.x86_64 Target RPM Packages Policy RPM selinux-policy-3.12.1-197.fc20.noarch Selinux Enabled True Policy Type targeted Enforcing Mode Enforcing Host Name localhost.localdomain Platform Linux localhost.localdomain 3.11.10-301.fc20.x86_64 #1 SMP Thu Dec 5 14:01:17 UTC 2013 x86_64 x86_64 Alert Count 4 First Seen 2015-07-18 18:20:02 MDT Last Seen 2015-07-18 18:50:01 MDT Local ID d59f7aa5-d595-46be-8186-412acb6133bf
Raw Audit Messages type=AVC msg=audit(1437267001.953:644): avc: denied { read } for pid=6476 comm="sa1" name="root" dev="sda3" ino=47972353 scontext=system_u:system_r:sysstat_t:s0-s0:c0.c1023 tcontext=system_u:object_r:admin_home_t:s0 tclass=dir
sudo debugfs -R 'ncheck 47972353' /dev/sda3 2>/dev/null
Should tell you the file being accessed along with the path.
type=SYSCALL msg=audit(1437267001.953:644): arch=x86_64 syscall=openat success=no exit=EACCES a0=ffffffffffffff9c a1=4fcb93 a2=80800 a3=0 items=0 ppid=6474 pid=6476 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 ses=22 tty=(none) comm=sa1 exe=/usr/bin/sh subj=system_u:system_r:sysstat_t:s0-s0:c0.c1023 key=(null)
Hash: sa1,sysstat_t,admin_home_t,dir,read
On 07/18/2015 07:10 PM, Ed Greshko wrote:
sudo debugfs -R 'ncheck 47972353' /dev/sda3 2>/dev/null
debugfs -R 'ncheck 47972353' /dev/sda3 2>/dev/null Inode Pathname 47972353 //root
So, why is it trying to do that? I am not logged in as root.
How can I find out the process(es) that spawned sh to access /root?
On 07/19/15 09:17, jd1008 wrote:
debugfs -R 'ncheck 47972353' /dev/sda3 2>/dev/null Inode Pathname 47972353 //root
So, why is it trying to do that? I am not logged in as root.
How can I find out the process(es) that spawned sh to access /root?
OK, so you have determined that the path being accessed and cited by the alert is /root.
Don't know if the process is still around, but supposedly it was pid=6476.
On 07/18/2015 07:53 PM, Ed Greshko wrote:
On 07/19/15 09:17, jd1008 wrote:
debugfs -R 'ncheck 47972353' /dev/sda3 2>/dev/null Inode Pathname 47972353 //root
So, why is it trying to do that? I am not logged in as root.
How can I find out the process(es) that spawned sh to access /root?
OK, so you have determined that the path being accessed and cited by the alert is /root.
Don't know if the process is still around, but supposedly it was pid=6476.
This is frustrating!! $ ps -p 6476 PID TTY TIME CMD $
On 07/19/15 09:57, jd1008 wrote:
On 07/18/2015 07:53 PM, Ed Greshko wrote:
On 07/19/15 09:17, jd1008 wrote:
debugfs -R 'ncheck 47972353' /dev/sda3 2>/dev/null Inode Pathname 47972353 //root
So, why is it trying to do that? I am not logged in as root.
How can I find out the process(es) that spawned sh to access /root?
OK, so you have determined that the path being accessed and cited by the alert is /root.
Don't know if the process is still around, but supposedly it was pid=6476.
This is frustrating!! $ ps -p 6476 PID TTY TIME CMD $
That should then mean that the pid= on each sealert is different. Yes?
On 07/18/2015 08:09 PM, Ed Greshko wrote:
On 07/19/15 09:57, jd1008 wrote:
On 07/18/2015 07:53 PM, Ed Greshko wrote:
On 07/19/15 09:17, jd1008 wrote:
debugfs -R 'ncheck 47972353' /dev/sda3 2>/dev/null Inode Pathname 47972353 //root
So, why is it trying to do that? I am not logged in as root.
How can I find out the process(es) that spawned sh to access /root?
OK, so you have determined that the path being accessed and cited by the alert is /root.
Don't know if the process is still around, but supposedly it was pid=6476.
This is frustrating!! $ ps -p 6476 PID TTY TIME CMD $
That should then mean that the pid= on each sealert is different. Yes?
The original I posted says:
type=SYSCALL msg=audit(1437267001.953:644): arch=x86_64 syscall=openat success=no exit=EACCES a0=ffffffffffffff9c a1=4fcb93 a2=80800 a3=0 items=0 ppid=6474 pid=6476 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 ses=22 tty=(none) comm=sa1 exe=/usr/bin/sh subj=system_u:system_r:sysstat_t:s0-s0:c0.c1023 key=(null)
So, it says pid=6476
but by the time I see the alert, the process is gone!!
On 07/19/15 10:17, jd1008 wrote:
The original I posted says:
type=SYSCALL msg=audit(1437267001.953:644): arch=x86_64 syscall=openat success=no exit=EACCES a0=ffffffffffffff9c a1=4fcb93 a2=80800 a3=0 items=0 ppid=6474 pid=6476 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 ses=22 tty=(none) comm=sa1 exe=/usr/bin/sh subj=system_u:system_r:sysstat_t:s0-s0:c0.c1023 key=(null)
So, it says pid=6476
but by the time I see the alert, the process is gone!!
Yes, that was the one you posted. You said you had others. So, the pid is different in each one, yes?
The question would be, what is the frequency of sealerts? Could it correspond with a cronjob?
Also, do you have sysstat-collect.timer and sysstat.service enabled in systemd?
On 07/18/2015 08:46 PM, Ed Greshko wrote:
On 07/19/15 10:17, jd1008 wrote:
The original I posted says:
type=SYSCALL msg=audit(1437267001.953:644): arch=x86_64 syscall=openat success=no exit=EACCES a0=ffffffffffffff9c a1=4fcb93 a2=80800 a3=0 items=0 ppid=6474 pid=6476 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 ses=22 tty=(none) comm=sa1 exe=/usr/bin/sh subj=system_u:system_r:sysstat_t:s0-s0:c0.c1023 key=(null)
So, it says pid=6476
but by the time I see the alert, the process is gone!!
Yes, that was the one you posted. You said you had others. So, the pid is different in each one, yes?
The question would be, what is the frequency of sealerts? Could it correspond with a cronjob?
Also, do you have sysstat-collect.timer and sysstat.service enabled in systemd?
It is gosh darned fast!!!! Like every 2 minutes.
$ sudo systemctl -l | grep sysstat sysstat.service loaded active exited Resets System Activity Logs
As far as cron, I do not see anyhting that is being run that frequently.
On 07/19/15 10:57, jd1008 wrote:
It is gosh darned fast!!!! Like every 2 minutes.
$ sudo systemctl -l | grep sysstat sysstat.service loaded active exited Resets System Activity Logs
Sorry I wasn't explicit ....
[root@meimei ~]# systemctl is-enabled sysstat-collect.timer enabled [root@meimei ~]# systemctl is-enabled sysstat.service enabled
If they are enabled, disable them for the time being and check to see if the sealerts cease.
Also, check this label
[root@meimei ~]# ls -Z /usr/lib64/sa/sa1 system_u:object_r:sysstat_exec_t:s0 /usr/lib64/sa/sa1
On 07/18/2015 09:18 PM, Ed Greshko wrote:
On 07/19/15 11:12, Ed Greshko wrote:
If they are enabled, disable them for the time being and check to see if the sealerts cease.
I should have said "stop" and "disable" them.
Done! and problem solved!!! Thanx a lot!!! Much appreciated!!!
On 07/20/15 07:31, jd1008 wrote:
On 07/18/2015 09:18 PM, Ed Greshko wrote:
On 07/19/15 11:12, Ed Greshko wrote:
If they are enabled, disable them for the time being and check to see if the sealerts cease.
I should have said "stop" and "disable" them.
Done! and problem solved!!! Thanx a lot!!! Much appreciated!!!
Well, it didn't "solve" the problem. It masked it. Those services run just fine here and elsewhere.
On 07/19/2015 05:45 PM, Ed Greshko wrote:
On 07/20/15 07:31, jd1008 wrote:
On 07/18/2015 09:18 PM, Ed Greshko wrote:
On 07/19/15 11:12, Ed Greshko wrote:
If they are enabled, disable them for the time being and check to see if the sealerts cease.
I should have said "stop" and "disable" them.
Done! and problem solved!!! Thanx a lot!!! Much appreciated!!!
Well, it didn't "solve" the problem. It masked it. Those services run just fine here and elsewhere.
If I re-enable them and the problem returns, then I have to look elsewhere as to the real cause of the problem - but I would still disable them.
On 07/20/15 08:47, jd1008 wrote:
On 07/19/2015 05:45 PM, Ed Greshko wrote:
On 07/20/15 07:31, jd1008 wrote:
On 07/18/2015 09:18 PM, Ed Greshko wrote:
On 07/19/15 11:12, Ed Greshko wrote:
If they are enabled, disable them for the time being and check to see if the sealerts cease.
I should have said "stop" and "disable" them.
Done! and problem solved!!! Thanx a lot!!! Much appreciated!!!
Well, it didn't "solve" the problem. It masked it. Those services run just fine here and elsewhere.
If I re-enable them and the problem returns, then I have to look elsewhere as to the real cause of the problem - but I would still disable them.
Did you check the label on /usr/lib64/sa/sa1 ?
You could also consider going through a relabel of your entire system. I've not run into problems with selinux but I've know others who have done things which, over time, necessitated a relabel as opposed to playing whack-a-mole.
You choice, but just like rust spots on a car, problems plastered over often cause greater headaches later.
On 07/19/2015 07:00 PM, Ed Greshko wrote:
On 07/20/15 08:47, jd1008 wrote:
On 07/19/2015 05:45 PM, Ed Greshko wrote:
On 07/20/15 07:31, jd1008 wrote:
On 07/18/2015 09:18 PM, Ed Greshko wrote:
On 07/19/15 11:12, Ed Greshko wrote:
If they are enabled, disable them for the time being and check to see if the sealerts cease.
I should have said "stop" and "disable" them.
Done! and problem solved!!! Thanx a lot!!! Much appreciated!!!
Well, it didn't "solve" the problem. It masked it. Those services run just fine here and elsewhere.
If I re-enable them and the problem returns, then I have to look elsewhere as to the real cause of the problem - but I would still disable them.
Did you check the label on /usr/lib64/sa/sa1 ?
You could also consider going through a relabel of your entire system. I've not run into problems with selinux but I've know others who have done things which, over time, necessitated a relabel as opposed to playing whack-a-mole.
You choice, but just like rust spots on a car, problems plastered over often cause greater headaches later.
I forgot the file I touch in / to force a relabel, something like .relabel=true ???
On 07/19/2015 08:27 PM, Ed Greshko wrote:
On 07/20/15 09:39, jd1008 wrote:
I forgot the file I touch in / to force a relabel, something like .relabel=true ???
touch /.autorelabel google would have found that for you.
Yep! I found it in a fedoraproject forum message right after I sent the email. I was just replying that I had forgotten it, with the intent of looking it up :)
After doing that and rebooting, I got 16 alerts.
Here is one of them:
SELinux is preventing /usr/bin/python2.7 from *remove_name*access on the directory .
***** Plugin catchall (100. confidence) suggests **************************
If you believe that python2.7 should be allowed remove_name access on the directory by default. Then you should report this as a bug. You can generate a local policy module to allow this access. Do allow this access for now by executing: # grep python /var/log/audit/audit.log | audit2allow -M mypol # semodule -i mypol.pp
Additional Information: Source Context system_u:system_r:blueman_t:s0-s0:c0.c1023 Target Context system_u:object_r:tmp_t:s0 Target Objects [ dir ] Source python Source Path /usr/bin/python2.7 Port <Unknown> Host localhost.localdomain Source RPM Packages python-2.7.5-16.fc20.x86_64 Target RPM Packages Policy RPM selinux-policy-3.12.1-197.fc20.noarch Selinux Enabled True Policy Type targeted Enforcing Mode Permissive Host Name localhost.localdomain Platform Linux localhost.localdomain 3.11.10-301.fc20.x86_64 #1 SMP Thu Dec 5 14:01:17 UTC 2013 x86_64 x86_64 Alert Count 1 First Seen 2015-07-20 10:14:10 MDT Last Seen 2015-07-20 10:14:10 MDT Local ID d167f2ee-4c4c-442e-877f-5a725536ec97
Raw Audit Messages type=AVC msg=audit(1437408850.342:377): avc: denied { remove_name } for pid=2582 comm="python" name="ffiuVaXeC" dev="tmpfs" ino=28942 scontext=system_u:system_r:blueman_t:s0-s0:c0.c1023 tcontext=system_u:object_r:tmp_t:s0 tclass=dir
type=AVC msg=audit(1437408850.342:377): avc: denied { unlink } for pid=2582 comm="python" name="ffiuVaXeC" dev="tmpfs" ino=28942 scontext=system_u:system_r:blueman_t:s0-s0:c0.c1023 tcontext=system_u:object_r:tmp_t:s0 tclass=file
type=SYSCALL msg=audit(1437408850.342:377): arch=x86_64 syscall=unlink success=yes exit=0 a0=7fffd3473a60 a1=c2 a2=180 a3=1 items=0 ppid=2581 pid=2582 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 ses=4294967295 tty=(none) comm=python exe=/usr/bin/python2.7 subj=system_u:system_r:blueman_t:s0-s0:c0.c1023 key=(null)
Hash: python,blueman_t,tmp_t,dir,remove_name
The rest are summarised as: SELinux is preventing /usr/bin/python2.7 from execute access on the file .
SELinux is preventing /usr/sbin/lightdm from write access on the directory .
SELinux is preventing /usr/sbin/lightdm from append access on the file .
The rest of the 16 alerts are all re: write access
Please note that I have stopped and disabled sysstat-collect.timerand sysstat.service since my previous reply.
Also note that I fully re-installed fresh due to the frustration since my first report about this thread.
On 07/20/2015 09:44 AM, jd1008 wrote:
Source RPM Packages python-2.7.5-16.fc20.x86_64 Target RPM Packages Policy RPM selinux-policy-3.12.1-197.fc20.noarch
Fedora 20 is EOL. There will be no further updates. Troubleshooting policy errors in outdated packages is largely a waste of time.
Your system is in permissive mode, so these alerts aren't actually interfering with the system's operation.
On 07/20/2015 11:43 AM, Gordon Messmer wrote:
On 07/20/2015 09:44 AM, jd1008 wrote:
Source RPM Packages python-2.7.5-16.fc20.x86_64 Target RPM Packages Policy RPM selinux-policy-3.12.1-197.fc20.noarch
Fedora 20 is EOL. There will be no further updates. Troubleshooting policy errors in outdated packages is largely a waste of time.
Your system is in permissive mode, so these alerts aren't actually interfering with the system's operation.
But I did not set it into permissive mode. I finished installing it mid-day yesterday, and did not alter selinux's config files. So, now I need to go look at those files again.
On 07/20/2015 11:50 AM, Joe Zeff wrote:
On 07/20/2015 10:45 AM, jd1008 wrote:
But I did not set it into permissive mode. I finished installing it mid-day yesterday,
Why did you install a version that you knew was past EOL?
For confidential apps I have no source for, only binaries which demand the fc20 version of various libs.
On 07/20/2015 10:58 AM, jd1008 wrote:
On 07/20/2015 11:50 AM, Joe Zeff wrote:
On 07/20/2015 10:45 AM, jd1008 wrote:
But I did not set it into permissive mode. I finished installing it mid-day yesterday,
Why did you install a version that you knew was past EOL?
For confidential apps I have no source for, only binaries which demand the fc20 version of various libs.
Asked and answered. Thank you.
On 07/20/2015 11:43 AM, Gordon Messmer wrote:
On 07/20/2015 09:44 AM, jd1008 wrote:
Source RPM Packages python-2.7.5-16.fc20.x86_64 Target RPM Packages Policy RPM selinux-policy-3.12.1-197.fc20.noarch
Fedora 20 is EOL. There will be no further updates. Troubleshooting policy errors in outdated packages is largely a waste of time.
Your system is in permissive mode, so these alerts aren't actually interfering with the system's operation.
/etc/sysconfig/selinux says:
# This file controls the state of SELinux on the system. # SELINUX= can take one of these three values: # enforcing - SELinux security policy is enforced. # permissive - SELinux prints warnings instead of enforcing. # disabled - No SELinux policy is loaded. SELINUX=enforcing # SELINUXTYPE= can take one of these two values: # targeted - Targeted processes are protected, # minimum - Modification of targeted policy. Only selected processes are protected. # mls - Multi Level Security protection. SELINUXTYPE=targeted
So, how did it become permissive??
On 07/20/2015 11:57 AM, Gordon Messmer wrote:
On 07/20/2015 10:47 AM, jd1008 wrote:
So, how did it become permissive??
We have no way to answer that. Your audit log would record the time at which the system entered permissive mode.
How incredibly mysterious is that?
here are a few of the lines from audit.log. All of the output of the command below showed .......permissive=0
# grep -i permissive audit.log
type=AVC msg=audit(1437355414.517:526): avc: denied { write } for pid=2365 comm="blueman-mechani" name="/" dev="tmpfs" ino=13776 scontext=system_u:system_r:blueman_t:s0-s0:c0.c1023 tcontext=system_u:object_r:tmp_t:s0 tclass=dir permissive=0 type=AVC msg=audit(1437355414.517:527): avc: denied { write } for pid=2365 comm="blueman-mechani" name="/" dev="debugfs" ino=1 scontext=system_u:system_r:blueman_t:s0-s0:c0.c1023 tcontext=system_u:object_r:debugfs_t:s0 tclass=dir permissive=0 type=AVC msg=audit(1437355414.517:528): avc: denied { write } for pid=2365 comm="blueman-mechani" name="/" dev="nfsd" ino=1 scontext=system_u:system_r:blueman_t:s0-s0:c0.c1023 tcontext=system_u:object_r:nfsd_fs_t:s0 tclass=dir permissive=0 type=AVC msg=audit(1437355414.517:529): avc: denied { write } for pid=2365 comm="blueman-mechani" name="/" dev="sdb3" ino=2 scontext=system_u:system_r:blueman_t:s0-s0:c0.c1023 tcontext=system_u:object_r:default_t:s0 tclass=dir permissive=0 type=AVC msg=audit(1437355414.517:530): avc: denied { write } for pid=2365 comm="blueman-mechani" name="/" dev="fusectl" ino=1 scontext=system_u:system_r:blueman_t:s0-s0:c0.c1023 tcontext=system_u:object_r:fusefs_t:s0 tclass=dir permissive=0
Hello folks,
It happened to me too that about a week or so ago SELinux automatically turned to 'Permissive' with an upgrade of selinux-related packages, I had to relabel everything to get things back to its previous state.
Although I didn't delve in the issue at that moment I will keep an eye on this issue should it happens again.
Cheers, -MartÃn
On 07/20/2015 12:23 PM, Martin Cigorraga wrote:
Hello folks,
It happened to me too that about a week or so ago SELinux automatically turned to 'Permissive' with an upgrade of selinux-related packages, I had to relabel everything to get things back to its previous state.
Although I didn't delve in the issue at that moment I will keep an eye on this issue should it happens again.
Cheers, -MartÃn
So how did yo set it back to Enforcing?
Hi,
I created the file /.autorelabel (# touch /.autorelabel), set SELinux to 'enforcing' and (/etc/sysconfig/selinux) and rebooted.
May be I could do it without rebooting as stated in this question: https://serverfault.com/questions/453137/how-can-i-do-an-selinux-filesystem-... but before landind there I was unaware of the 'fixfiles' tool :)
HTH, let us know if not.
On Mon, Jul 20, 2015 at 3:31 PM jd1008 jd1008@gmail.com wrote:
On 07/20/2015 12:23 PM, Martin Cigorraga wrote:
Hello folks,
It happened to me too that about a week or so ago SELinux automatically turned to 'Permissive' with an upgrade of selinux-related packages, I had to relabel everything to get things back to its previous state.
Although I didn't delve in the issue at that moment I will keep an eye on this issue should it happens again.
Cheers, -MartÃn
So how did yo set it back to Enforcing?
-- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
On 07/20/2015 12:38 PM, Martin Cigorraga wrote:
I created the file /.autorelabel (# touch /.autorelabel), set SELinux
to 'enforcing' and (/etc/sysconfig/selinux) and rebooted.
May be I could do it without rebooting as stated in this question:
https://serverfault.com/questions/453137/how-can-i-do-an-selinux-filesystem-... but before landind there I was unaware of the 'fixfiles' tool :)
HTH, let us know if not.
On Mon, Jul 20, 2015 at 3:31 PM jd1008 <jd1008@gmail.com mailto:jd1008@gmail.com> wrote:
On 07/20/2015 12:23 PM, Martin Cigorraga wrote: > Hello folks, > > It happened to me too that about a week or so ago SELinux > automatically turned to 'Permissive' with an upgrade of > selinux-related packages, I had to relabel everything to get things > back to its previous state. > > Although I didn't delve in the issue at that moment I will keep an eye > on this issue should it happens again. > > Cheers, > -MartÃn > > > > > > > So how did yo set it back to Enforcing?
But that is exactly what I did Ii.e. I touched .autorelabel) and rebooted and when the reply came thatmy selinux was set to permissive, I replied with the contents of my /etc/sysconfig/selinux. It is set to enforcing.
So how is it that in runtime, it is permissive???
So, I am led to believe that from the get-go, fedora has a backdoor!!
On 07/20/2015 12:38 PM, Martin Cigorraga wrote:
Hi,
I created the file /.autorelabel (# touch /.autorelabel), set SELinux to 'enforcing' and (/etc/sysconfig/selinux) and rebooted.
May be I could do it without rebooting as stated in this question: https://serverfault.com/questions/453137/how-can-i-do-an-selinux-filesystem-... before landind there I was unaware of the 'fixfiles' tool :)
HTH, let us know if not.
On Mon, Jul 20, 2015 at 3:31 PM jd1008 <jd1008@gmail.com mailto:jd1008@gmail.com> wrote:
On 07/20/2015 12:23 PM, Martin Cigorraga wrote: > Hello folks, > > It happened to me too that about a week or so ago SELinux > automatically turned to 'Permissive' with an upgrade of > selinux-related packages, I had to relabel everything to get things > back to its previous state. > > Although I didn't delve in the issue at that moment I will keep an eye > on this issue should it happens again. > > Cheers, > -MartÃn > > > > > > > So how did yo set it back to Enforcing?
After I executed setenforce Enforcing touched /.autorelabel and rebooted, during the reboot, the labeling was taking place, and I saw 3 messages, which I cannot see anywhere in /var/log. The messages included that plymouthd killed systemd and that some file or directory in /lib/modules/ had too many symlinks or some such, and the relabeling died at when it was at about 13%.
Hi,
~ getenforce Enforcing
Please be aware that setenforce will only change the mode SELinux is running in. For a permanent change, you have to edit the configuration file.
On Mon, Jul 20, 2015 at 4:32 PM jd1008 jd1008@gmail.com wrote:
On 07/20/2015 12:38 PM, Martin Cigorraga wrote:
Hi,
I created the file /.autorelabel (# touch /.autorelabel), set SELinux to 'enforcing' and (/etc/sysconfig/selinux) and rebooted.
May be I could do it without rebooting as stated in this question:
https://serverfault.com/questions/453137/how-can-i-do-an-selinux-filesystem-...
before landind there I was unaware of the 'fixfiles' tool :)
HTH, let us know if not.
On Mon, Jul 20, 2015 at 3:31 PM jd1008 <jd1008@gmail.com mailto:jd1008@gmail.com> wrote:
On 07/20/2015 12:23 PM, Martin Cigorraga wrote: > Hello folks, > > It happened to me too that about a week or so ago SELinux > automatically turned to 'Permissive' with an upgrade of > selinux-related packages, I had to relabel everything to get things > back to its previous state. > > Although I didn't delve in the issue at that moment I will keep an eye > on this issue should it happens again. > > Cheers, > -MartÃn > > > > > > > So how did yo set it back to Enforcing?After I executed setenforce Enforcing touched /.autorelabel and rebooted, during the reboot, the labeling was taking place, and I saw 3 messages, which I cannot see anywhere in /var/log. The messages included that plymouthd killed systemd and that some file or directory in /lib/modules/ had too many symlinks or some such, and the relabeling died at when it was at about 13%.
-- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
On 07/20/2015 01:42 PM, Martin Cigorraga wrote:
Hi,
~ getenforce Enforcing
Please be aware that setenforce will only change the mode SELinux is running in. For a permanent change, you have to edit the configuration file.
I already stated that /etc/sysconfig/selinux says (and did say when my system was in permissive mode):
# $ sudo cat /etc/sysconfig/selinux
# This file controls the state of SELinux on the system. # SELINUX= can take one of these three values: # enforcing - SELinux security policy is enforced. # permissive - SELinux prints warnings instead of enforcing. # disabled - No SELinux policy is loaded. SELINUX=enforcing # SELINUXTYPE= can take one of these two values: # targeted - Targeted processes are protected, # minimum - Modification of targeted policy. Only selected processes are protected. # mls - Multi Level Security protection. SELINUXTYPE=targeted
Thus going into permissive mode was not done by me. As I also stated, this is a fresh install since mid-day, yesterday, with only yum update bringing in new versions of packages.
You can just run
# restorecon -R -v /
From the booted machine.
On 07/20/2015 03:49 PM, jd1008 wrote:
On 07/20/2015 01:42 PM, Martin Cigorraga wrote:
Hi,
~ getenforce Enforcing
Please be aware that setenforce will only change the mode SELinux is running in. For a permanent change, you have to edit the configuration file.
I already stated that /etc/sysconfig/selinux says (and did say when my system was in permissive mode):
# $ sudo cat /etc/sysconfig/selinux
# This file controls the state of SELinux on the system. # SELINUX= can take one of these three values: # enforcing - SELinux security policy is enforced. # permissive - SELinux prints warnings instead of enforcing. # disabled - No SELinux policy is loaded. SELINUX=enforcing # SELINUXTYPE= can take one of these two values: # targeted - Targeted processes are protected, # minimum - Modification of targeted policy. Only selected processes are protected. # mls - Multi Level Security protection. SELINUXTYPE=targeted
Thus going into permissive mode was not done by me. As I also stated, this is a fresh install since mid-day, yesterday, with only yum update bringing in new versions of packages.
On 07/21/2015 06:49 AM, Daniel J Walsh wrote:
On 07/20/2015 03:49 PM, jd1008 wrote:
On 07/20/2015 01:42 PM, Martin Cigorraga wrote:
Hi,
~ getenforce Enforcing
Please be aware that setenforce will only change the mode SELinux is running in. For a permanent change, you have to edit the configuration file.
I already stated that /etc/sysconfig/selinux says (and did say when my system was in permissive mode):
# $ sudo cat /etc/sysconfig/selinux
# This file controls the state of SELinux on the system. # SELINUX= can take one of these three values: # enforcing - SELinux security policy is enforced. # permissive - SELinux prints warnings instead of enforcing. # disabled - No SELinux policy is loaded. SELINUX=enforcing # SELINUXTYPE= can take one of these two values: # targeted - Targeted processes are protected, # minimum - Modification of targeted policy. Only selected processes are protected. # mls - Multi Level Security protection. SELINUXTYPE=targeted
Thus going into permissive mode was not done by me. As I also stated, this is a fresh install since mid-day, yesterday, with only yum update bringing in new versions of packages.
You can just run
# restorecon -R -v /
From the booted machine.
I got numerous warning messages for many files, like this:
restorecon: Warning no default label for /var/tmp/dnf-jd-SzbEwA
So, if there is no default label, what does that mean to the user?
On 07/21/2015 06:49 AM, Daniel J Walsh wrote:
On 07/20/2015 03:49 PM, jd1008 wrote:
On 07/20/2015 01:42 PM, Martin Cigorraga wrote:
Hi,
~ getenforce Enforcing
Please be aware that setenforce will only change the mode SELinux is running in. For a permanent change, you have to edit the configuration file.
I already stated that /etc/sysconfig/selinux says (and did say when my system was in permissive mode):
# $ sudo cat /etc/sysconfig/selinux
# This file controls the state of SELinux on the system. # SELINUX= can take one of these three values: # enforcing - SELinux security policy is enforced. # permissive - SELinux prints warnings instead of enforcing. # disabled - No SELinux policy is loaded. SELINUX=enforcing # SELINUXTYPE= can take one of these two values: # targeted - Targeted processes are protected, # minimum - Modification of targeted policy. Only selected processes are protected. # mls - Multi Level Security protection. SELINUXTYPE=targeted
Thus going into permissive mode was not done by me. As I also stated, this is a fresh install since mid-day, yesterday, with only yum update bringing in new versions of packages.
You can just run
# restorecon -R -v /
From the booted machine.
After running the command, and rebooting, I am still getting 14 alerts. 2 of them caused by lightdm: one for append access and the other for write access. 12 of them are cause by python 2.7; one of which is for execute access and the rest are for write access.
On 07/18/2015 08:46 PM, Ed Greshko wrote:
On 07/19/15 10:17, jd1008 wrote:
The original I posted says:
type=SYSCALL msg=audit(1437267001.953:644): arch=x86_64 syscall=openat success=no exit=EACCES a0=ffffffffffffff9c a1=4fcb93 a2=80800 a3=0 items=0 ppid=6474 pid=6476 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 ses=22 tty=(none) comm=sa1 exe=/usr/bin/sh subj=system_u:system_r:sysstat_t:s0-s0:c0.c1023 key=(null)
So, it says pid=6476
but by the time I see the alert, the process is gone!!
Yes, that was the one you posted. You said you had others. So, the pid is different in each one, yes?
The question would be, what is the frequency of sealerts? Could it correspond with a cronjob?
Also, do you have sysstat-collect.timer and sysstat.service enabled in systemd?
So, why is the auditd running so freaking often???
TO wit (from the alert that JUST happened):
type=SYSCALL msg=audit(1437274801.754:808): arch=x86_64 syscall=openat success=no exit=EACCES a0=ffffffffffffff9c a1=4fcb93 a2=80800 a3=0 items=0 ppid=8525 pid=8527 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 ses=37 tty=(none) comm=sa1 exe=/usr/bin/sh subj=system_u:system_r:sysstat_t:s0-s0:c0.c1023 key=(null)
Hash: sa1,sysstat_t,admin_home_t,dir,read
On 07/18/2015 09:11 PM, Joe Zeff wrote:
On 07/18/2015 08:02 PM, jd1008 wrote:
egid=0 sgid=0 fsgid=0 ses=37 tty=(none) comm=sa1 exe=/usr/bin/sh subj=system_u:system_r:sysstat_t:s0-s0:c0.c1023
Right there's you're answer: /usr/bin/sh, AKA bash.
Well, who, or more exactly, what is forking a bash script to read /root ?
On Sat, Jul 18, 2015 at 10:02 PM, jd1008 jd1008@gmail.com wrote:
On 07/18/2015 08:46 PM, Ed Greshko wrote:
On 07/19/15 10:17, jd1008 wrote:
The original I posted says:
type=SYSCALL msg=audit(1437267001.953:644): arch=x86_64 syscall=openat success=no exit=EACCES a0=ffffffffffffff9c a1=4fcb93 a2=80800 a3=0 items=0 ppid=6474 pid=6476 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 ses=22 tty=(none) comm=sa1 exe=/usr/bin/sh subj=system_u:system_r:sysstat_t:s0-s0:c0.c1023 key=(null)
So, it says pid=6476
but by the time I see the alert, the process is gone!!
Yes, that was the one you posted. You said you had others. So, the pid is different in each one, yes?
The question would be, what is the frequency of sealerts? Could it correspond with a cronjob?
Also, do you have sysstat-collect.timer and sysstat.service enabled in systemd?
So, why is the auditd running so freaking often???
TO wit (from the alert that JUST happened):
type=SYSCALL msg=audit(1437274801.754:808): arch=x86_64 syscall=openat success=no exit=EACCES a0=ffffffffffffff9c a1=4fcb93 a2=80800 a3=0 items=0 ppid=8525 pid=8527 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 ses=37 tty=(none) comm=sa1 exe=/usr/bin/sh subj=system_u:system_r:sysstat_t:s0-s0:c0.c1023 key=(null)
sa1 appears to be the culprit. It is normally run from a cronjob typically every 10 minutes.
John
On 07/19/15 11:26, inode0 wrote:
sa1 appears to be the culprit. It is normally run from a cronjob typically every 10 minutes.
See my other message....
[root@meimei ~]# systemctl is-enabled sysstat-collect.timer enabled [root@meimei ~]# systemctl is-enabled sysstat.service enabled
If they are enabled, stop and disable them for the time being and check to see if the sealerts cease.
Also, check this label
[root@meimei ~]# ls -Z /usr/lib64/sa/sa1
system_u:object_r:sysstat_exec_t:s0 /usr/lib64/sa/sa1
/usr/lib64/sa/sa1 is a shell script and called very 10 minutes based on the settings in sysstat-collect.timer
On 07/18/2015 07:10 PM, Ed Greshko wrote:
On 07/19/15 09:00, jd1008 wrote:
The sealert below does not tell me exactly which dir that the shell tried to access. I have run the suggested commands (below) but they did not do any good. The alerts keep popping up.
SELinux is preventing /usr/bin/sh from read access on the directory .
***** Plugin catchall (100. confidence) suggests **************************
If you believe that sh should be allowed read access on the directory by default. Then you should report this as a bug. You can generate a local policy module to allow this access. Do allow this access for now by executing: # grep sa1 /var/log/audit/audit.log | audit2allow -M mypol # semodule -i mypol.pp
Additional Information: Source Context system_u:system_r:sysstat_t:s0-s0:c0.c1023 Target Context system_u:object_r:admin_home_t:s0 Target Objects [ dir ] Source sa1 Source Path /usr/bin/sh Port <Unknown> Host localhost.localdomain Source RPM Packages sh-20120801-23.fc20.x86_64 Target RPM Packages Policy RPM selinux-policy-3.12.1-197.fc20.noarch Selinux Enabled True Policy Type targeted Enforcing Mode Enforcing Host Name localhost.localdomain Platform Linux localhost.localdomain 3.11.10-301.fc20.x86_64 #1 SMP Thu Dec 5 14:01:17 UTC 2013 x86_64 x86_64 Alert Count 4 First Seen 2015-07-18 18:20:02 MDT Last Seen 2015-07-18 18:50:01 MDT Local ID d59f7aa5-d595-46be-8186-412acb6133bf
Raw Audit Messages type=AVC msg=audit(1437267001.953:644): avc: denied { read } for pid=6476 comm="sa1" name="root" dev="sda3" ino=47972353 scontext=system_u:system_r:sysstat_t:s0-s0:c0.c1023 tcontext=system_u:object_r:admin_home_t:s0 tclass=dir
sudo debugfs -R 'ncheck 47972353' /dev/sda3 2>/dev/null
Should tell you the file being accessed along with the path.
Also, /dev/sda3 has no dir named root:
$ ls /sda3/root /bin/ls: cannot access /sda3/root: No such file or directory
On 07/19/15 09:20, jd1008 wrote:
Also, /dev/sda3 has no dir named root:
$ ls /sda3/root /bin/ls: cannot access /sda3/root: No such file or directory
Of course not, since there probably is no /sda3 directory.
Does
sudo ls -l -i /* | grep 47972353
return a filename?
On 07/18/2015 07:53 PM, Ed Greshko wrote:
On 07/19/15 09:51, jd1008 wrote:
On 07/18/2015 07:46 PM, Ed Greshko wrote:
sudo ls -l -i /* | grep 47972353
$ ls -l -i /* | grep 47972353 $
Nop!
And why did you not use "sudo" as shown?
Ooops, Sorry. Here it is: $ sudo ls -l -i /* | grep 47972353 $
On 07/18/2015 08:07 PM, Ed Greshko wrote:
On 07/19/15 09:55, jd1008 wrote:
Ooops, Sorry. Here it is: $ sudo ls -l -i /* | grep 47972353
OK.... How about
sudo ls -l -i -R /root | grep 47972353
Well, now, this is interesting:
$ sudo ls -l -i -R /root | grep 47972353 <<<<< Produced no output $ sudo ls -l -d -i -R /root | grep 47972353 <<<<<< adding the -d option, however: 47972353 dr-xr-x---. 9 root root 4096 Jul 2 14:03 /root $
I really want to find which daemon/process is ultimately causing sh to try to read /root and open it for reading? Hopefully that might shed some light on why it is happening.
On 07/19/15 10:15, jd1008 wrote:
Well, now, this is interesting:
$ sudo ls -l -i -R /root | grep 47972353 <<<<< Produced no output $ sudo ls -l -d -i -R /root | grep 47972353 <<<<<< adding the -d option, however: 47972353 dr-xr-x---. 9 root root 4096 Jul 2 14:03 /root $
I really want to find which daemon/process is ultimately causing sh to try to read /root and open it for reading? Hopefully that might shed some light on why it is happening.
First make sure it is labeled correctly
[egreshko@meimei ~]$ ls -Zd /root system_u:object_r:admin_home_t:s0 /root
On 07/18/2015 08:20 PM, Ed Greshko wrote:
On 07/19/15 10:15, jd1008 wrote:
Well, now, this is interesting:
$ sudo ls -l -i -R /root | grep 47972353 <<<<< Produced no output $ sudo ls -l -d -i -R /root | grep 47972353 <<<<<< adding the -d option, however: 47972353 dr-xr-x---. 9 root root 4096 Jul 2 14:03 /root $
I really want to find which daemon/process is ultimately causing sh to try to read /root and open it for reading? Hopefully that might shed some light on why it is happening.
First make sure it is labeled correctly
[egreshko@meimei ~]$ ls -Zd /root system_u:object_r:admin_home_t:s0 /root
$ ls -Zd /root dr-xr-x---. root root system_u:object_r:admin_home_t:s0 /root/ $
On my output, there is a / after root
I am sure it is of no real consequence, but ..... there is always a but !! :)
-
Daniel J Walsh -
Ed Greshko -
Gordon Messmer -
inode0 -
JD -
Joe Zeff -
Martin Cigorraga