SELinux and Shorewall with IPSets
by Mr Dash Four
Problems combining these 2 to run while SELinux is in 'enforced' mode
(policy running is the 'stock' targeted one supplied with FC13). I get 2
audit alerts when Shorewall starts (and fails!) - see logs below. I have
x86_64 arch machine with FC13 running. Stock Shorewall is installed.
IPSet (xtunnels) is compiled in (though with the 'stock' rpm I am
getting the same errors).
The problem seems to be caused by the Shorewall init script (see further
below). The relevant part of my syslog when SELinux is in enforced mode is:
=========SELinux=Enforcing================================
Jun 26 23:18:38 dev1 shorewall[2456]: Compiling...
Jun 26 23:18:38 dev1 kernel: type=1400 audit(1277590718.634:29543):
avc: denied { create } for pid=2577 comm="ipset"
scontext=unconfined_u:system_r:shorewall_t:s0
tcontext=unconfined_u:system_r:shorewall_t:s0 tclass=rawip_socket
Jun 26 23:18:38 dev1 kernel: type=1400 audit(1277590718.637:29544):
avc: denied { create } for pid=2579 comm="ipset"
scontext=unconfined_u:system_r:shorewall_t:s0
tcontext=unconfined_u:system_r:shorewall_t:s0 tclass=rawip_socket
Jun 26 23:18:38 dev1 shorewall[2456]: Compiling /etc/shorewall/zones...
Jun 26 23:18:38 dev1 shorewall[2456]: Compiling /etc/shorewall/interfaces...
Jun 26 23:18:38 dev1 shorewall[2456]: Determining Hosts in Zones...
Jun 26 23:18:38 dev1 shorewall[2456]: Preprocessing Action Files...
Jun 26 23:18:38 dev1 shorewall[2456]: Pre-processing
/usr/share/shorewall/action.Drop...
Jun 26 23:18:38 dev1 shorewall[2456]: Pre-processing
/usr/share/shorewall/action.Reject...
Jun 26 23:18:38 dev1 shorewall[2456]: Compiling /etc/shorewall/policy...
Jun 26 23:18:38 dev1 shorewall[2456]: Compiling /etc/shorewall/blacklist...
Jun 26 23:18:38 dev1 shorewall[2456]: ERROR: ipset names in Shorewall
configuration files require Ipset Match in your kernel and iptables :
/etc/shorewall/blacklist (line 11)
Jun 26 23:18:38 dev1 shorewall[2456]: ERROR: Shorewall start failed
==========================================================
When I switch SELinux to Permissive I get two further errors:
=========SELinux=Permissive===============================
Jun 26 23:32:45 dev1 kernel: type=1400 audit(1277591565.629:29551):
avc: denied { create } for pid=3799 comm="ipset"
scontext=unconfined_u:system_r:shorewall_t:s0
tcontext=unconfined_u:system_r:shorewall_t:s0 tclass=rawip_socket
Jun 26 23:32:45 dev1 kernel: type=1400 audit(1277591565.629:29552):
avc: denied { getopt } for pid=3799 comm="ipset" lport=255
scontext=unconfined_u:system_r:shorewall_t:s0
tcontext=unconfined_u:system_r:shorewall_t:s0 tclass=rawip_socket
Jun 26 23:32:45 dev1 kernel: type=1400 audit(1277591565.629:29553):
avc: denied { setopt } for pid=3799 comm="ipset" lport=255
scontext=unconfined_u:system_r:shorewall_t:s0
tcontext=unconfined_u:system_r:shorewall_t:s0 tclass=rawip_socket
Jun 26 23:32:45 dev1 shorewall[3678]: Compiling /etc/shorewall/zones...
Jun 26 23:32:45 dev1 shorewall[3678]: Compiling /etc/shorewall/interfaces...
Jun 26 23:32:45 dev1 shorewall[3678]: Determining Hosts in Zones...
Jun 26 23:32:45 dev1 shorewall[3678]: Preprocessing Action Files...
Jun 26 23:32:45 dev1 shorewall[3678]: Pre-processing
/usr/share/shorewall/action.Drop...
Jun 26 23:32:45 dev1 shorewall[3678]: Pre-processing
/usr/share/shorewall/action.Reject...
Jun 26 23:32:45 dev1 shorewall[3678]: Compiling /etc/shorewall/policy...
Jun 26 23:32:45 dev1 shorewall[3678]: Compiling /etc/shorewall/blacklist...
Jun 26 23:32:45 dev1 shorewall[3678]: Adding Anti-smurf Rules
Jun 26 23:32:45 dev1 shorewall[3678]: Compiling TCP Flags filtering...
Jun 26 23:32:45 dev1 shorewall[3678]: Compiling Kernel Route Filtering...
Jun 26 23:32:45 dev1 shorewall[3678]: Compiling Martian Logging...
Jun 26 23:32:45 dev1 shorewall[3678]: Compiling MAC Filtration -- Phase 1...
Jun 26 23:32:45 dev1 shorewall[3678]: Compiling /etc/shorewall/rules...
Jun 26 23:32:45 dev1 shorewall[3678]: Generating Transitive Closure of
Used-action List...
Jun 26 23:32:45 dev1 shorewall[3678]: Processing
/usr/share/shorewall/action.Reject for chain Reject...
Jun 26 23:32:45 dev1 shorewall[3678]: Processing
/usr/share/shorewall/action.Drop for chain Drop...
Jun 26 23:32:45 dev1 shorewall[3678]: Compiling MAC Filtration -- Phase 2...
Jun 26 23:32:45 dev1 shorewall[3678]: Applying Policies...
Jun 26 23:32:45 dev1 shorewall[3678]: Generating Rule Matrix...
Jun 26 23:32:45 dev1 shorewall[3678]: Creating iptables-restore input...
Jun 26 23:32:45 dev1 shorewall[3678]: Compiling iptables-restore input
for chains blacklst mangle:...
Jun 26 23:32:45 dev1 shorewall[3678]: Shorewall configuration compiled
to /var/lib/shorewall/.start
Jun 26 23:32:45 dev1 shorewall[3678]: Starting Shorewall....
Jun 26 23:32:45 dev1 shorewall[3678]: Initializing...
Jun 26 23:32:46 dev1 kernel: u32 classifier
Jun 26 23:32:46 dev1 kernel: Performance counters on
Jun 26 23:32:46 dev1 kernel: input device check on
Jun 26 23:32:46 dev1 kernel: Actions configured
Jun 26 23:32:46 dev1 shorewall[3678]: Processing /etc/shorewall/init ...
Jun 26 23:32:46 dev1 shorewall[3678]: loading
/etc/shorewall/ips/blacklist-x1.ips
Jun 26 23:32:46 dev1 shorewall[3678]: loading
/etc/shorewall/ips/blacklist-x2.ips
Jun 26 23:32:46 dev1 shorewall[3678]: loading
/etc/shorewall/ips/blacklist-z1.ips
Jun 26 23:32:47 dev1 shorewall[3678]: loading
/etc/shorewall/ips/blacklist-z2.ips
Jun 26 23:32:49 dev1 shorewall[3678]: Processing /etc/shorewall/tcclear ...
Jun 26 23:32:49 dev1 shorewall[3678]: Setting up Route Filtering...
Jun 26 23:32:49 dev1 shorewall[3678]: Setting up Martian Logging...
Jun 26 23:32:49 dev1 shorewall[3678]: Setting up Proxy ARP...
Jun 26 23:32:49 dev1 shorewall[3678]: Setting up Traffic Control...
Jun 26 23:32:49 dev1 shorewall[3678]: Preparing iptables-restore input...
Jun 26 23:32:49 dev1 shorewall[3678]: Running /sbin/iptables-restore...
Jun 26 23:32:49 dev1 shorewall[3678]: IPv4 Forwarding Enabled
Jun 26 23:32:49 dev1 shorewall[3678]: Processing /etc/shorewall/start ...
Jun 26 23:32:49 dev1 shorewall[3678]: Processing /etc/shorewall/started ...
Jun 26 23:32:49 dev1 shorewall[3678]: Shorewall started
==========================================================
The problem seems to be caused by the shorewall init script, which is:
===========Shorewall init script==========================
modprobe ifb numifbs=1
ip link set dev ifb0 up
# configure the ipsets
sw_ips_mask='/etc/shorewall/ips/*.ips'
ipset_exec='/usr/sbin/ipset'
if [ "$COMMAND" = start ]; then
$ipset_exec -F
$ipset_exec -X
for c in `/bin/ls $sw_ips_mask 2>/dev/null`; do
echo loading $c
$ipset_exec -R < $c
done
fi
==========================================================
The above script executes /usr/sbin/ipset to create my IP Sets needed
for running Shorewall (all IP set commands are contained in those *.ips
files). These IP sets comprise mainly of IP subnets which are part of my
blacklists (banned IP subnets), though they also contain some IP Port
sets as well.
Don't know why SELinux denies "create" (and then "getopt" and "setopt")
on a, what seems to be, raw ip socket (IPSet do not use/need one as far
as I know!)? If I remove the IP Set part of the init script above and
rearrange Shorewall to run without IPSets all is well, though its
functionality is VERY limited and barely useful to me!
Two questions to the SELinux gurus on here: 1) Why am I getting these
alerts? and 2) How can I fix the problem so that I could run both
Shorewall and IPSets with SELinux in Enforced mode?
This is important for me as this is a production server and a lot of
stuff runs on it and needs to be available 24/7.
Many thanks in advance!
12 years, 11 months
sandbox window size
by Christoph A.
Hi,
as far as I have seen and read it is not possible to resize a SELinux
sandbox window.
Is it possible to specify the size of the sandbox at start-time?
kind regards,
Christoph
13 years, 3 months
Re: [refpolicy] [PATCH] revise roles/dbadm.te (Re: dbadm.pp is not available in selinux-policy package)
by KaiGai Kohei
(2010/04/14 0:57), Christopher J. PeBenito wrote:
> On Tue, 2010-04-13 at 11:15 -0400, Daniel J Walsh wrote:
>> -----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.
>
> Good point. We should probably reconsider the setfiles usage from
> webadm too.
The attached patch is a revised one.
- seutil_domtrans_setfiles() was removed
- staff_role_change_to() was removed, and I put dbadm_role_change()
on the staff.te
- Fix an obvious typo.
It is not clear for me whether the idea to allow relabelfrom/relabelto
for all the files dbadm_t can manage, because it is eventually necessary
someone to relabel (or assign initial labels) files from unlabeled one
to managed labels when we mount a new disk.
If so, should it be a task of sysadm_t to mount new disk and assign
security context correctly, instead of webadm_t/dbadm_t?
Thanks,
--
KaiGai Kohei <kaigai(a)ak.jp.nec.com>
13 years, 3 months
Cannot turn off port forwarding for sshd
by Sergey Noskov
Hello.
I have a guest user with the guest_t domain. I want this user to connect
the network only for a few of allowed ports. It works when user connects
to the host by ssh and tries to connect network, but not when it tries
to do it using ssh port forwarding.
By default, the sshd policy allows the sshd daemon to connect any tcp
port: there is the string in ssh.if file in ssh_server_template definition:
corenet_tcp_connect_all_ports($1_t)
I comment this string and recompile the module,but port forwarding wtill
works. I also grep the tmp/ssh.tmp file to be sure, that access, i.e. to
httpd_port_t is not enabled by this module, but only dns, ldap, and a
bunch of other ports not including any http port.
This request:
sesearch -SC --allow -s sshd_t -c tcp_socket -p name_connect
gives me the same port list as in .tmp file(dns and ldap) and two
strings with those cryptic @ttr which I cannot understand.
Adding
auditallow domain port_type:tcp_socket name_connect;
makes the record in logs when I connect to forwarded port:
type=AVC msg=audit(1276082912.292:133): avc: granted { name_connect }
for pid=4872 comm="sshd" dest=80
scontext=system_u:system_r:sshd_t:s0-s0:c0.c1023
tcontext=system_u:object_r:http_port_t:s0 tclass=tcp_socket
Steps I do to make forwarding:
ssh -L 9234:any-www-host:80 -f -p 22 -l guest -N my-selinux-host
wget 'http://localhost:9234'
and see, that file is loaded, so port forwarding happens.
I've also tried to change the sshd_t for other name to make sure it's
not allowed directly somewhere in the base policy or other modules. It's
not.
So, I have 2 questions here:
1. Shouldn't the ssh forwarding be the boolean in the policy?
2. What should I modify now(or how to find, what to modify) to deny sshd
connects to ports at all?
--
Regards,
Sergey Noskov
13 years, 5 months
Apache/PHP mail function SELinux permissions
by Ted Rule
I've had a "problem" recently with SELinux permissions related to PHP's
mail functions. These appear to give rise to two different classes of error,
one for read permissions on the httpd_t domain itself, and one for
read/write permission on a file in the httpd_tmp_t domain.
aureport gives this:
$ sudo aureport -a |grep system_mail |head
6. 25/10/09 13:12:48 sendmail user_u:system_r:system_mail_t:s0 11 file
read user_u:system_r:httpd_t:s0 denied 116101
7. 25/10/09 13:15:57 sendmail user_u:system_r:system_mail_t:s0 11 file
read write user_u:object_r:httpd_tmp_t:s0 denied 116102
17. 25/10/09 13:39:46 sendmail user_u:system_r:system_mail_t:s0 11 file
read write user_u:object_r:httpd_tmp_t:s0 denied 116124
23. 25/10/09 13:43:04 sendmail user_u:system_r:system_mail_t:s0 11 file
read write user_u:object_r:httpd_tmp_t:s0 denied 116136
24. 25/10/09 13:43:04 sendmail user_u:system_r:system_mail_t:s0 11 file
read user_u:system_r:httpd_t:s0 denied 116136
30. 25/10/09 13:52:57 sendmail user_u:system_r:system_mail_t:s0 11 file
read write user_u:object_r:httpd_tmp_t:s0 denied 116148
31. 25/10/09 13:52:57 sendmail user_u:system_r:system_mail_t:s0 11 file
read user_u:system_r:httpd_t:s0 denied 116148
39. 25/10/09 14:01:18 sendmail user_u:system_r:system_mail_t:s0 11 file
read write user_u:object_r:httpd_tmp_t:s0 denied 116168
40. 25/10/09 14:01:18 sendmail user_u:system_r:system_mail_t:s0 11 file
read user_u:system_r:httpd_t:s0 denied 116168
48. 25/10/09 14:11:50 sendmail user_u:system_r:system_mail_t:s0 11 file
read write user_u:object_r:httpd_tmp_t:s0 denied 116181
Policy on the Apache hosts currently uses selinux-policy-2.4.6-203.el5
Looking in more detail at ausearch we see that the httpd_t related avc
is apparently related to an "eventpoll" file descriptor, whilst the
httpd_tmp_t
avc is probably for a file created by php in /tmp.
Looking at the php source code itself, I see that it is simply opening a
temporary file containing the body of the Email and pouring it via a
pipe into an instance of sendmail via popen().
As such, it seems likely that both classes of avc's are simply file
descriptors "leaking" into the popen'ed child process running in the
system_mail_t domain.
Sadly, for other reasons, the Apache hosts are still in permissive, so
it's currently unclear to me whether the PHP mail function would fail
completely if either
of these permissions are denied in enforcing mode, but it makes me
wonder whether there would be any sense in a wider solution to leaky
descriptors which caused popen() itself to close all file descriptors
other than STDIN/STDOUT/STDERR if the popen'ed executable implies a
domain transition. Alternatively, one might envisage a set of selinux
booleans which allowed a more granular control of leaked descriptors
outside of STDIN/STDOUT/STDERR.
The other potential policy improvement would be for system_mail_t to
simply "dontaudit" denials relating to eventpoll class file descriptors
and temporary files in context *_tmp_t.
time->Sun Oct 25 13:12:48 2009
type=SYSCALL msg=audit(1256476368.217:116101): arch=40000003 syscall=11
success=yes exit=0 a0=97e5ff0 a1=97e5798 a2=97e5600 a3=40 items=0
ppid=20809 pid=22040 auid=500 uid=48 gid=48 euid=
48 suid=48 fsuid=48 egid=51 sgid=51 fsgid=51 tty=(none) ses=11966
comm="sendmail" exe="/usr/sbin/sendmail.sendmail"
subj=user_u:system_r:system_mail_t:s0 key=(null)
type=AVC msg=audit(1256476368.217:116101): avc: denied { read } for
pid=22040 comm="sendmail" path="eventpoll:[129640960]" dev=eventpollfs
ino=129640960 scontext=user_u:system_r:system
_mail_t:s0 tcontext=user_u:system_r:httpd_t:s0 tclass=file
----
time->Sun Oct 25 13:15:57 2009
type=SYSCALL msg=audit(1256476557.234:116102): arch=40000003 syscall=11
success=yes exit=0 a0=9ab7ff0 a1=9ab7798 a2=9ab7600 a3=40 items=0
ppid=21767 pid=22099 auid=500 uid=48 gid=48 euid=
48 suid=48 fsuid=48 egid=51 sgid=51 fsgid=51 tty=(none) ses=11966
comm="sendmail" exe="/usr/sbin/sendmail.sendmail"
subj=user_u:system_r:system_mail_t:s0 key=(null)
type=AVC msg=audit(1256476557.234:116102): avc: denied { read write }
for pid=22099 comm="sendmail"
path=2F746D702F2E7863616368652E302E302E313032353230323336322E6C6F636B202864656C65746
56429 dev=dm-3 ino=97922 scontext=user_u:system_r:system_mail_t:s0
tcontext=user_u:object_r:httpd_tmp_t:s0 tclass=file
----
time->Sun Oct 25 13:39:46 2009
type=SYSCALL msg=audit(1256477986.012:116124): arch=40000003 syscall=11
success=yes exit=0 a0=97f1ff0 a1=97f1798 a2=97f1600 a3=40 items=0
ppid=23457 pid=23560 auid=500 uid=48 gid=48 euid=
48 suid=48 fsuid=48 egid=51 sgid=51 fsgid=51 tty=(none) ses=11966
comm="sendmail" exe="/usr/sbin/sendmail.sendmail"
subj=user_u:system_r:system_mail_t:s0 key=(null)
type=AVC msg=audit(1256477986.012:116124): avc: denied { read write }
for pid=23560 comm="sendmail"
path=2F746D702F2E7863616368652E302E302E313032353230323336322E6C6F636B202864656C65746
56429 dev=dm-3 ino=97922 scontext=user_u:system_r:system_mail_t:s0
tcontext=user_u:object_r:httpd_tmp_t:s0 tclass=file
----
time->Sun Oct 25 13:43:04 2009
type=SYSCALL msg=audit(1256478184.954:116136): arch=40000003 syscall=11
success=yes exit=0 a0=8f48ff0 a1=8f48798 a2=8f48600 a3=40 items=0
ppid=23048 pid=23802 auid=500 uid=48 gid=48 euid=
48 suid=48 fsuid=48 egid=51 sgid=51 fsgid=51 tty=(none) ses=11966
comm="sendmail" exe="/usr/sbin/sendmail.sendmail"
subj=user_u:system_r:system_mail_t:s0 key=(null)
type=AVC msg=audit(1256478184.954:116136): avc: denied { read } for
pid=23802 comm="sendmail" path="eventpoll:[129701955]" dev=eventpollfs
ino=129701955 scontext=user_u:system_r:system
_mail_t:s0 tcontext=user_u:system_r:httpd_t:s0 tclass=file
type=AVC msg=audit(1256478184.954:116136): avc: denied { read write }
for pid=23802 comm="sendmail"
path=2F746D702F2E7863616368652E302E302E313032353230323336322E6C6F636B202864656C65746
56429 dev=dm-3 ino=97922 scontext=user_u:system_r:system_mail_t:s0
tcontext=user_u:object_r:httpd_tmp_t:s0 tclass=file
----
time->Sun Oct 25 13:52:57 2009
type=SYSCALL msg=audit(1256478777.377:116148): arch=40000003 syscall=11
success=yes exit=0 a0=945bff0 a1=945b798 a2=945b600 a3=40 items=0
ppid=24396 pid=24439 auid=500 uid=48 gid=48 euid=
48 suid=48 fsuid=48 egid=51 sgid=51 fsgid=51 tty=(none) ses=11966
comm="sendmail" exe="/usr/sbin/sendmail.sendmail"
subj=user_u:system_r:system_mail_t:s0 key=(null)
type=AVC msg=audit(1256478777.377:116148): avc: denied { read } for
pid=24439 comm="sendmail" path="eventpoll:[129734033]" dev=eventpollfs
ino=129734033 scontext=user_u:system_r:system
_mail_t:s0 tcontext=user_u:system_r:httpd_t:s0 tclass=file
type=AVC msg=audit(1256478777.377:116148): avc: denied { read write }
for pid=24439 comm="sendmail"
path=2F746D702F2E7863616368652E302E302E313032353230323336322E6C6F636B202864656C65746
56429 dev=dm-3 ino=97922 scontext=user_u:system_r:system_mail_t:s0
tcontext=user_u:object_r:httpd_tmp_t:s0 tclass=file
----
--
Ted Rule
Director, Layer3 Systems Ltd
Layer3 Systems Limited is registered in England. Company no 3130393
W: http://www.layer3.co.uk/
13 years, 5 months
[ANN] node-selinux
by Ted Toth
http://github.com/tedx/node-selinux
For those who'd like to play with node.js and SELinux I started a
node.js modules for libselinux functions. At this point I've only
implemented a half dozen functions (someone should modify Swig to
produce node.js modules) and plan to add more time permitting. If
anyone wants to add to it and send me a patch that would be great.
Ted
13 years, 5 months
Re: I need to add "pass though" for milter-greylist on F8
by Dominick Grift
On 06/28/2010 06:08 PM, Daniel B. Thurman wrote:
> On 06/28/2010 12:45 AM, Dominick Grift wrote:
>> On 06/27/2010 11:10 PM, Daniel B. Thurman wrote:
>>
>>> I know that F8 is no longer supported, but I would like
>>> to know the steps to add my own "pass through" for
>>> the milter-graylist milter. I basically cannot start sendmail
>>> without the allowing AVC on the milter's socket.
>>>
>>> From: /var/log/audit/audit.log, I have:
>>>
>>> type=AVC msg=audit(1277670351.513:52178): avc: denied { getattr } for
>>> pid=30048 comm="sendmail"
>>> path="/var/run/milter-greylist/milter-greylist.sock" dev=sda3
>>> ino=4114571 scontext=unconfined_u:system_r:sendmail_t:s0
>>> tcontext=unconfined_u:object_r:var_run_t:s0 tclass=sock_file
>>>
>>> Thanks!
>>> Dan
>>>
>> Do you have the milter module installed (i suspect not):
>>
>>> $ semodule -l | grep milter
>>> milter 1.2.0
>>>
> No, milter is not found on F8
>> If you do not have it installed, then i guess you would need to back
>> port it to f8 and install it there.
>>
> How is this done? I am willing to do this in order to get greylisting
> milter (and other milters) working!
>> Then allow sendmail to (atleast) get attributes of milter pid sockets.
May not be so easy to do but try the following:
mkdir ~/milter; cd ~/milter;
touch milter.{te,if,fc}
in milter.te add the following:
http://fpaste.org/167B/
in milter.if add the following:
http://fpaste.org/XHVd/
in milter.fc add the following:
http://fpaste.org/iJGU/
And then first see if you can get this to build:
make -f /usr/share/selinux/devel/Makefile milter.pp
if it does compile:
run restorecon -R -v (..) for each path in milter.fc
else:
report the fail message so that we can try fix it.
Than reproduce the issue and report back the AVC denials you are seeying.
But i am afraid that building it might not be easy.
> Thanks for responding!
> Dan
>
13 years, 5 months
svnsync
by Vadym Chepkov
Hi,
I configured svnsync to be triggered from a subversion hook, to maintain remote replicas.
I had my own type for hooks defined, so audit2allow shows it.
This is what it suggests:
require {
type httpd_svn_script_t;
class netlink_route_socket { write getattr read bind create nlmsg_read };
}
#============= httpd_svn_script_t ==============
allow httpd_svn_script_t self:netlink_route_socket { write getattr read bind create nlmsg_read };
kernel_read_kernel_sysctls(httpd_svn_script_t)
I am kind of concerned about kernel bits, why would svnsync need it, I have no clue.
Also I can see a boolean httpd_can_network_relay, which is set to off by default and is not documented in man httpd_selinux.
Could it be related somehow?
Thanks,
Vadym Chepkov
13 years, 5 months
I need to add "pass though" for milter-greylist on F8
by Dan Thurman
I know that F8 is no longer supported, but I would like
to know the steps to add my own "pass through" for
the milter-graylist milter. I basically cannot start sendmail
without the allowing AVC on the milter's socket.
From: /var/log/audit/audit.log, I have:
type=AVC msg=audit(1277670351.513:52178): avc: denied { getattr } for
pid=30048 comm="sendmail"
path="/var/run/milter-greylist/milter-greylist.sock" dev=sda3
ino=4114571 scontext=unconfined_u:system_r:sendmail_t:s0
tcontext=unconfined_u:object_r:var_run_t:s0 tclass=sock_file
Thanks!
Dan
13 years, 5 months
selinux bugzilla?
by mark
I'm tired of this. I think it's time for me to file a bug report.
I have the current version of CA's Siteminder installed. I have the
current version of CentOS (5.5). I'm still getting selinux complaining
that siteminder can't write to its own logfiles.
ll -Z /var/log/httpd/smagent.log
-rw-r--r-- apache root system_u:object_r:httpd_log_t
/var/log/httpd/smagent.log
ll -Z /usr/local/opt/smwa-6qmr5-cr035-rhel30-x86-64/webagent/bin/LLAWP
-rwxrwxr-x root root system_u:object_r:bin_t
/usr/local/opt/smwa-6qmr5-cr035-rhel30-x86-64/webagent/bin/LLAWP*
I run sealert, and it tells me that I can allow this behavior by setting
httpd_unified on. It says that httpd_unified is off.
It's on. It's been on. Therefore, selinux's error handling has a bug, and
is falling through to an incorrect diagnosis.
So, can someone give me the link to selinux's bugzilla?
mark
13 years, 5 months
