selinux April 2010

selinux@lists.fedoraproject.org

31 participants
39 discussions

snmp Permission denied on mounted filesystems
by Paul Ward 15 Apr '10

15 Apr '10

I have run the command as follows but I am still getting the permission issues. Apr 16 11:48:13 sargas snmpd[23987]: /home/work/exports: Permission denied # restorecon -v /home/work/exports restorecon reset context /home/work/exports:->system_u:object_r:user_home_t ls -lZd /home/work/exports drwxrwxr-x oracle dba system_u:object_r:user_home_t /home/work/exports Whats next? Do I need to restart something? On 16 April 2010 11:11, Sandro Janke <gui1ty_fedora(a)penguinpee.nl> wrote: > On 04/16/2010 12:33 AM, Paul Ward wrote: >>> What does 'rpm -qv selinux-policy-targeted' say? >>> What are the settings in /etc/selinux/config? >> >> My server shows the following selinux packages. >> >> selinux-policy-targeted-1.17.30-2.152.el4 >> selinux-policy-targeted-sources-1.17.30-2.152.el4 >> >> I have run: >> snmpwalk -v 2c -c public .iso >> cd /etc/selinux/targeted/src/policy >> audit2allow -d -l -o domains/misc/local.te >> make load >> >> Until no more errors were found, this fixed theoriginal errors from >> selinux, but not the permissions. >> >>> Try running restorecon -R -v /home >> >> If I run >> >> restorecon -R -v /home >> >> Would this affect a production servers running or should I do this in >> a mainaintance window? > > Well, you can try to run it with the -n switch first to show you what > would happen. According to the man page: "It can be run at any time to > correct errors..." > >> On 15 April 2010 19:05, Sandro Janke <gui1ty_fedora(a)penguinpee.nl> wrote: >>> On 04/15/2010 06:49 AM, Paul Ward wrote: >>>> Hi all, >>>> >>>> I am sure this comes up a lot but have spent hours trying to find th >>>> eanswers with no success apart from disabling selinux which I don't >>>> want to do. >>>> >>>> Apr 15 16:48:26 sargas snmpd[23987]: /home/appl: Permission denied >>>> >>>> The following filesystems are mounted with same issue. >>>> >>>> /dev/sda7 3.9G 427M 3.3G 12% /home/appl >>>> /dev/sda6 4.0G 2.7G 1.2G 71% /home/users >>>> /dev/sda8 3.9G 2.5G 1.2G 68% /home/work >>>> >>>> ls -ldZ /home/appl/ >>>> drwxr-xr-x root root /home/appl/ >>> >>> This shows that the directory has not been labeled, yet. >>> >>>> /usr/sbin/sestatus >>>> SELinux status: enabled >>>> SELinuxfs mount: /selinux >>>> Current mode: enforcing >>>> >>> >>> Could it be that you don't have any policy package installed? >>> >>> What does 'rpm -qv selinux-policy-targeted' say? >>> What are the settings in /etc/selinux/config? >>> >>>> What do I need to do to fix this chcon? If so what is the full comman >>>> / context to enter? >>>> >>>> Thanks >>>> -- >>>> selinux mailing list >>>> selinux(a)lists.fedoraproject.org >>>> https://admin.fedoraproject.org/mailman/listinfo/selinux >>> >>> >> -- >> selinux mailing list >> selinux(a)lists.fedoraproject.org >> https://admin.fedoraproject.org/mailman/listinfo/selinux > >

1 0

snmp Permission denied on mounted filesystems
by Paul Ward 15 Apr '10

15 Apr '10

Hi all, I am sure this comes up a lot but have spent hours trying to find th eanswers with no success apart from disabling selinux which I don't want to do. Apr 15 16:48:26 sargas snmpd[23987]: /home/appl: Permission denied The following filesystems are mounted with same issue. /dev/sda7 3.9G 427M 3.3G 12% /home/appl /dev/sda6 4.0G 2.7G 1.2G 71% /home/users /dev/sda8 3.9G 2.5G 1.2G 68% /home/work ls -ldZ /home/appl/ drwxr-xr-x root root /home/appl/ /usr/sbin/sestatus SELinux status: enabled SELinuxfs mount: /selinux Current mode: enforcing What do I need to do to fix this chcon? If so what is the full comman / context to enter? Thanks

3 4

Another Fail2ban problem (I think)
by Arthur Dent 14 Apr '10

14 Apr '10

Hello all, As part of my security set-up I use, amongst other things, fail2ban. This has many well known problems with SELinux but, with help from this list in general and Dominick Grift in particular, I got a policy which has worked without problems since (see the thread here: https://www.redhat.com/archives/fedora-selinux-list/2009-December/msg00082.…) This culminated in the following policy: policy_module(myfail2ban, 11.2.1) optional_policy(` gen_require(` attribute domain; type fail2ban_t; ') dontaudit domain fail2ban_t:unix_stream_socket { read write }; ') Today, F2B successfully blocked a probing attempt. The offender's IP address is "dropped" in iptables, and the F2B server sent me an email to inform me of the ban (all as expected). Two slightly strange, and possibly unrelated things however... 1) The ban was not recorded in F2B's own log 2) I got (at exactly the time of the banning action) the following 2 AVCs: Raw Audit Messages : node=troodos.org.uk type=AVC msg=audit(1271226504.162:64635): avc: denied { read write } for pid=25646 comm="iptables" path="socket:[1307085]" dev=sockfs ino=1307085 scontext=unconfined_u:unconfined_r:iptables_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tclass=unix_dgram_socket node=troodos.org.uk type=SYSCALL msg=audit(1271226504.162:64635): arch=40000003 syscall=11 success=yes exit=0 a0=84a4e28 a1=84a50a8 a2=84a3a28 a3=84a50a8 items=0 ppid=25645 pid=25646 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="iptables" exe="/sbin/iptables" subj=unconfined_u:unconfined_r:iptables_t:s0-s0:c0.c1023 key=(null) Raw Audit Messages : node=troodos.org.uk type=AVC msg=audit(1271226505.377:64636): avc: denied { read write } for pid=25652 comm="iptables" path="socket:[1307085]" dev=sockfs ino=1307085 scontext=unconfined_u:unconfined_r:iptables_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tclass=unix_dgram_socket node=troodos.org.uk type=SYSCALL msg=audit(1271226505.377:64636): arch=40000003 syscall=11 success=yes exit=0 a0=836c018 a1=836bff0 a2=836aa28 a3=836bff0 items=0 ppid=2672 pid=25652 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="iptables" exe="/sbin/iptables" subj=unconfined_u:unconfined_r:iptables_t:s0-s0:c0.c1023 key=(null) Audit2allow thinks this: # cat avcs | audit2allow -M test ******************** IMPORTANT *********************** To make this policy package active, execute: semodule -i test.pp # cat test.te module test 1.0; require { type unconfined_t; type iptables_t; class unix_dgram_socket { read write }; } #============= iptables_t ============== allow iptables_t unconfined_t:unix_dgram_socket { read write }; The logging problem aside, F2B seems to have worked as normal. Should I include the above things in my policy or is there another approach? Thanks for any suggestions. Mark

2 1

cron/anacron discrepancy in Centos 5?
by Moray Henderson (ICT) 14 Apr '10

14 Apr '10

After I do a fresh install of a (slightly customised) CentOS 5, a logwatch run is kicked off by anacron. It tries to run a directory size scan, which generates a whole list of errors: du: cannot read directory `/var/log/audit': Permission denied du: cannot read directory `/var/log/pm': Permission denied ... du: cannot access `/usr/lib/sa/sa2': Permission denied du: cannot read directory `/usr/lib/httpd': Permission denied with corresponding AVCs: type=AVC msg=audit(1271158392.750:101): avc: denied { read } for pid=3429 comm="du" name="audit" dev=dm-4 ino=418914 scontext=system_u:system_r:logwatch_t:s0-s0:c0.c1023 tcontext=system_u:object_r:auditd_log_t:s0 tclass=dir type=AVC msg=audit(1271158392.845:102): avc: denied { read } for pid=3429 comm="du" name="pm" dev=dm-4 ino=418940 scontext=system_u:system_r:logwatch_t:s0-s0:c0.c1023 tcontext=system_u:object_r:hald_log_t:s0 tclass=dir ... type=AVC msg=audit(1271158414.619:266): avc: denied { getattr } for pid=3432 comm="du" path="/usr/lib/sa/sa2" dev=dm-1 ino=457413 scontext=system_u:system_r:logwatch_t:s0-s0:c0.c1023 tcontext=system_u:object_r:sysstat_exec_t:s0 tclass=file type=AVC msg=audit(1271158414.648:267): avc: denied { read } for pid=3432 comm="du" name="httpd" dev=dm-1 ino=422750 scontext=system_u:system_r:logwatch_t:s0-s0:c0.c1023 tcontext=system_u:object_r:httpd_modules_t:s0 tclass=dir However, once the system has settled down and logwatch is being run by cron, the errors no longer appear. Both cron and anacron have the same type: -rwxr-xr-x root root system_u:object_r:crond_exec_t /usr/sbin/anacron -rwxr-xr-x root root system_u:object_r:crond_exec_t /usr/sbin/crond -rwxr-xr-x root root system_u:object_r:logwatch_exec_t /usr/share/logwatch/scripts/logwatch.pl So why does it fail from one and work from the other? Moray. "To err is human. To purr, feline"

1 0

List Archives?
by Arthur Dent 14 Apr '10

14 Apr '10

Wishing to refer to previous correspondence for my recent post, I looked at the archives for this mailing list. https://www.redhat.com/archives/fedora-selinux-list/ I was a little surprised to find that the archives seem to stop at January 9 of this year. Is this a known problem? Mark

2 2

munin-run has other SELinux privileges as munin-node
by Gabriele Pohl 13 Apr '10

13 Apr '10

Hi, some sentences on the background of the question I will ask below: "munin-run" is a utility delivered with the package "munin-node". Its purpose is testing the execution of munin plugins in an environment that is equate to the execution when called by daemon "munin-node". When exploring the new Munin version 1.4.4 on Fedora Core 12 I found out, that this does not work in sense of testing "SELinux-Privileges". I got reasonable values from a plugin, when I run it on the node: ----- 8< ----- # munin-run selinux_avcstat lookups.value 25863367 hits.value 25837715 misses.value 25652 allocations.value 25657 reclaims.value 24624 frees.value 25156 ----- >8 ----- and get "Unknown" values, when I fetch the values from munin-node by master via telnet: ----- 8< ----- # telnet localhost 4949 Trying 127.0.0.1... Connected to localhost. Escape character is '^]'. # munin node at localhost fetch selinux_avcstat lookups.value U hits.value U misses.value U allocations.value U reclaims.value U frees.value U . ----- >8 ----- After setting SELinux mode to *permissive* it worked also for the munin-node: # telnet localhost 4949 Trying 127.0.0.1... Connected to localhost. Escape character is '^]'. # munin node at localhost fetch selinux_avcstat lookups.value 33223592 hits.value 33194702 misses.value 28890 allocations.value 28900 reclaims.value 27856 frees.value 28392 . Now my question: 1. Why was it possible to get values (read the file: /selinux/avc/cache_stats) when calling the plugin with munin-run and also directly under user "munin" ----- 8< ----- sudo -u munin /etc/munin/plugins/selinux_avcstat lookups.value 29744406 hits.value 29717050 misses.value 27356 allocations.value 27361 reclaims.value 26320 frees.value 26852 ----- >8 ----- but not for "munin-node"? Because this is a daemon? 2. Is it possible to create a tool "munin-run" that is able to test the SELinux issues for munin-node also? 3. What rule will I have to add to my Munin Policy to allow munin-node to read the file /selinux/avc/cache_stats? 4. I there no QA on munins standard plugin collection delivered by Fedora? These SELinux issues one gets everytime with the Munin-Packages are really annoying.. *sigh* and best regards, Gabriele

2 2

Re: [refpolicy] [PATCH] revise roles/dbadm.te (Re: dbadm.pp is not available in selinux-policy package)
by Daniel J Walsh 13 Apr '10

13 Apr '10

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 04/13/2010 09:17 AM, Christopher J. PeBenito wrote: > On Tue, 2010-04-13 at 09:28 +0900, KaiGai Kohei wrote: >> (2010/04/12 23:09), Christopher J. PeBenito wrote: >>> On Fri, 2010-04-09 at 14:29 +0900, KaiGai Kohei wrote: >>>> (2010/04/08 21:15), Daniel J Walsh wrote: >>>>> As Dominick stated. I prefer to think in terms of two different roles. >>>>> Login Roles, and Roles to execute in when you have privileges (IE Root). >>>>> >>>>> Login Roles/Types >>>>> staff_t, user_t, unconfined_t, xguest_t, guest_t >>>>> >>>>> Three interfaces can be used to create confined login users. >>>>> >>>>> userdom_restricted_user_template(guest) >>>>> userdom_restricted_xwindows_user_template(xguest) >>>>> userdom_unpriv_user_template(staff) >>>>> >>>>> >>>>> Admin Roles/Types >>>>> logadm_t, webadm_t, secadm_t, auditadm_t >>>>> >>>>> The following interface can be used to create an Admin ROle >>>>> userdom_base_user_template(logadm) >>>>> >>>>> >>>>> sysadm_t is sort of a hybrid, most people use it as an Admin Role. >>>>> >>>>> >>>>> I imagine that you login as a confined user and then use sudo/newrole to >>>>> switch roles to one of the admin roles. >>>> >>>> The attached patch revises roles/dbadm.te (to be applied on the upstream >>>> reference policy). It uses userdom_base_user_template() instead of the >>>> userdom_unpriv_user_template(), and should be launched via sudo/newrole. >>>> In the default, it intends the dbadm_r role to be launched by staff_r role. >>> >>> Why does dbadm need to run setfiles? >> >> The database files (typically, /var/lib/(se)?pgsql/*) have to be labeled >> correctly, so I thought dbadm needs to run setfiles. >> However, as long as they initialize database files using init script, >> initrc_t domain performs this initial labeling, so it might not be necessary. >> >> On the other hand, PostgreSQL support a feature to use multiple disks >> within a single database instance for performance utilization. >> (Called TABLESPACE; I don't know whether MySQL has such a feature.) >> >> http://archives.postgresql.org/pgsql-general/2006-08/msg00142.php >> >> It requires administrators to assign proper security context on the secondary >> directory, or to mount the secondary disk with context='...' option. >> >> Is there any good idea? >> >> Or, it should not be a task for dbadm? > > Ok, the transition for setfiles is fine. > I would be carefull with this. Since setfiles can take a parameter of a file context file. I think it would be better to only give relabefrom/relabelto privs for all labels dbadm_t can manage. Then figure out what access is required to mount. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAkvEioAACgkQrlYvE4MpobPgIwCgtK9sqyPvRhj90hfQFZU+ZlpJ H6UAoIrrEMw2dv/1/QR9Oi/J1iXBhqrx =dfmE -----END PGP SIGNATURE-----

1 0

Re: [refpolicy] [PATCH] revise roles/dbadm.te (Re: dbadm.pp is not available in selinux-policy package)
by KaiGai Kohei 12 Apr '10

12 Apr '10

(2010/04/12 23:09), Christopher J. PeBenito wrote: > On Fri, 2010-04-09 at 14:29 +0900, KaiGai Kohei wrote: >> (2010/04/08 21:15), Daniel J Walsh wrote: >>> -----BEGIN PGP SIGNED MESSAGE----- >>> Hash: SHA1 >>> >>> As Dominick stated. I prefer to think in terms of two different roles. >>> Login Roles, and Roles to execute in when you have privileges (IE Root). >>> >>> Login Roles/Types >>> staff_t, user_t, unconfined_t, xguest_t, guest_t >>> >>> Three interfaces can be used to create confined login users. >>> >>> userdom_restricted_user_template(guest) >>> userdom_restricted_xwindows_user_template(xguest) >>> userdom_unpriv_user_template(staff) >>> >>> >>> Admin Roles/Types >>> logadm_t, webadm_t, secadm_t, auditadm_t >>> >>> The following interface can be used to create an Admin ROle >>> userdom_base_user_template(logadm) >>> >>> >>> sysadm_t is sort of a hybrid, most people use it as an Admin Role. >>> >>> >>> I imagine that you login as a confined user and then use sudo/newrole to >>> switch roles to one of the admin roles. >> >> The attached patch revises roles/dbadm.te (to be applied on the upstream >> reference policy). It uses userdom_base_user_template() instead of the >> userdom_unpriv_user_template(), and should be launched via sudo/newrole. >> In the default, it intends the dbadm_r role to be launched by staff_r role. > > Why does dbadm need to run setfiles? The database files (typically, /var/lib/(se)?pgsql/*) have to be labeled correctly, so I thought dbadm needs to run setfiles. However, as long as they initialize database files using init script, initrc_t domain performs this initial labeling, so it might not be necessary. On the other hand, PostgreSQL support a feature to use multiple disks within a single database instance for performance utilization. (Called TABLESPACE; I don't know whether MySQL has such a feature.) http://archives.postgresql.org/pgsql-general/2006-08/msg00142.php It requires administrators to assign proper security context on the secondary directory, or to mount the secondary disk with context='...' option. Is there any good idea? Or, it should not be a task for dbadm? > Use of staff_role_change_to() is not allowed upstream. If staff should > be allowed to change to dbadm, the dbadm_role_change() should be used in > the staff module. OK, I'll fix it. Thanks, -- KaiGai Kohei <kaigai(a)ak.jp.nec.com>

1 0

milter policy hardening
by Paul Howarth 12 Apr '10

12 Apr '10

Here I have a couple of changes to the milter policy that reduce what milters (well, spamass-milter in particular) are able to do. Firstly, I noticed a while back that I was getting AVCs from milter-regex and milter-greylist trying to read /proc/cpuinfo at program start-up. I couldn't figure out what was causing that to happen (probably part of some system call or maybe in libmilter) but this access being denied didn't seem to cause any problems. I also saw that the spamass-milter policy allowed this access. A few weeks ago I updated my local policy to dontaudit this instead of allowing it and don't appear to be suffering any problems as a result, so I propose to dontaudit it in the milter template. Secondly, the fix for CVE-2010-1132 in spamass-milter was just pushed to stable for all supported Fedora and EPEL releases. This was unsanitized input being passed in an argument to popen() and hence a shell. Upstream proposed a patch for this several weeks ago that replaced the popen() call with execve() via a wrapper called popenv(), which avoids the use of a shell for this functionality. This fix hasn't been committed to upstream CVS yet but I have tested it extensively myself and this fix has been incorporated into the Fedora and Debian spamass-milter packages. So for Fedora and Debian, the following policy rules are no longer needed: corecmd_exec_shell(spamass_milter_t) corecmd_search_bin(spamass_milter_t) These changes are all included in the attached patch against Rawhide policy. Paul.

2 1

EMC NetWorker
by Paul Howarth 12 Apr '10

12 Apr '10

EMC NetWorker is a proprietary enterprise backup solution, and one of the first steps in its install guide is to disable SELinux. No thanks. Adding the following file contexts to local policy gets it running just fine with SELinux enforcing: /nsr(/.*)? gen_context(system_u:object_r:var_t,s0) /nsr/logs(/.*)? gen_context(system_u:object_r:var_log_t,s0) /usr/lib/nsr/(.*/)?.*\.so gen_context(system_u:object_r:textrel_shlib_t,s0) /opt/lgtonmc/bin/.*\.so(\.[0-9])? gen_context(system_u:object_r:textrel_shlib_t,s0) Note: the /usr/lib/nsr/ context is the right one even on x86_64 systems. Paul.

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

selinux April 2010