snmp Permission denied on mounted filesystems
by Paul Ward
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
>
>
14 years
snmp Permission denied on mounted filesystems
by Paul Ward
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
14 years
Another Fail2ban problem (I think)
by Arthur Dent
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/msg0008...)
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
14 years
cron/anacron discrepancy in Centos 5?
by Moray Henderson (ICT)
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"
14 years
munin-run has other SELinux privileges as munin-node
by Gabriele Pohl
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
14 years
Re: [refpolicy] [PATCH] revise roles/dbadm.te (Re: dbadm.pp is not available in selinux-policy package)
by Daniel J Walsh
-----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-----
14 years
Re: [refpolicy] [PATCH] revise roles/dbadm.te (Re: dbadm.pp is not available in selinux-policy package)
by KaiGai Kohei
(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>
14 years
milter policy hardening
by Paul Howarth
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.
14 years, 1 month
EMC NetWorker
by Paul Howarth
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.
14 years, 1 month