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, 7 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, 8 months
Mod-security (mlogc) problem
by Arthur Dent
Hello all,
I believe in a multi-layered approach towards security, so as well as
SELinux I use Mod-Security to protect the web server on my F11 machine.
Recently I started using the ModSecurity Community Console to analyse
the mod-security denials. This requires using the mlogc logging
application that comes bundled with the mod_security-2.5.12-1.fc11.i586
package.
Now every time a mod-security denial is triggered I get 3 SEL AVCs
(currently in permissive mode while I sort this out). They say:
SELinux has denied the mlogc access to potentially mislabeled files /var/run/pcscd.pid. This means that SELinux will not allow httpd to use these files. Many third party apps install html files in directories that SELinux policy cannot predict. These directories have to be labeled with a file context which httpd can access.
If you want to change the file context of /var/run/pcscd.pid so that the
httpd daemon can access it, you need to execute it using chcon -t
httpd_sys_content_t '/var/run/pcscd.pid'.
A similar one for /var/run/pcsd.pub
and then one for:
SELinux is preventing the mlogc from using potentially mislabeled files
636F6F6C6B6579706B313173452D47617465203020302D30 (auth_cache_t).
(Actual AVCs below)
If I try doing the chcon -t httpd_sys_content_t '/var/run/pcscd.xxx' as
recommended by sealert I only get the one with the strange filename each
time I get a mod-sec alert. However, now of course I get this:
SELinux denied access requested by certwatch. /var/run/pcscd.pub may be a mislabeled. /var/run/pcscd.pub default SELinux type is pcscd_var_run_t, but its current type is httpd_sys_content_t. Changing this file back to the default type, may fix your problem.
(and another one for .pid)
So I need to put the file context back to what it was using
restorecon....
Audit2allow suggests this:
require {
type auth_cache_t;
type httpd_t;
type pcscd_var_run_t;
class file { read write getattr open };
}
#============= httpd_t ==============
allow httpd_t auth_cache_t:file { read write };
allow httpd_t pcscd_var_run_t:file { read getattr open };
What do you think is the best solution to this problem?
Thanks in advance for any help or suggestions...
Mark
AVCs
====
Raw Audit Messages :
node=troodos.org.uk type=AVC msg=audit(1270480904.700:37928): avc: denied { read } for pid=9674 comm="mlogc" name="pcscd.pid" dev=sda5 ino=362220 scontext=unconfined_u:system_r:httpd_t:s0 tcontext=system_u:object_r:pcscd_var_run_t:s0 tclass=file
node=troodos.org.uk type=AVC msg=audit(1270480904.700:37928): avc: denied { open } for pid=9674 comm="mlogc" name="pcscd.pid" dev=sda5 ino=362220 scontext=unconfined_u:system_r:httpd_t:s0 tcontext=system_u:object_r:pcscd_var_run_t:s0 tclass=file
node=troodos.org.uk type=SYSCALL msg=audit(1270480904.700:37928): arch=40000003 syscall=5 success=yes exit=10 a0=d348ea a1=0 a2=1b6 a3=d348e8 items=0 ppid=9643 pid=9674 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="mlogc" exe="/usr/bin/mlogc" subj=unconfined_u:system_r:httpd_t:s0 key=(null)
Raw Audit Messages :
node=troodos.org.uk type=AVC msg=audit(1270488357.977:38184): avc: denied { getattr } for pid=10531 comm="mlogc" path="/var/run/pcscd.pub" dev=sda5 ino=362221 scontext=unconfined_u:system_r:httpd_t:s0 tcontext=system_u:object_r:pcscd_var_run_t:s0 tclass=file
node=troodos.org.uk type=SYSCALL msg=audit(1270488357.977:38184): arch=40000003 syscall=195 success=yes exit=0 a0=d345ab a1=b64279ac a2=d1eff4 a3=3 items=0 ppid=9643 pid=10531 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="mlogc" exe="/usr/bin/mlogc" subj=unconfined_u:system_r:httpd_t:s0 key=(null)
Raw Audit Messages :
node=troodos.org.uk type=AVC msg=audit(1270488685.640:38200): avc: denied { read write } for pid=10661 comm="mlogc" name=636F6F6C6B6579706B313173452D47617465203020302D30 dev=sda5 ino=372384 scontext=unconfined_u:system_r:httpd_t:s0 tcontext=system_u:object_r:auth_cache_t:s0 tclass=file
node=troodos.org.uk type=SYSCALL msg=audit(1270488685.640:38200): arch=40000003 syscall=5 success=yes exit=12 a0=b5830dc0 a1=20002 a2=180 a3=b5830da8 items=0 ppid=10644 pid=10661 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="mlogc" exe="/usr/bin/mlogc" subj=unconfined_u:system_r:httpd_t:s0 key=(null)
13 years, 10 months
tar xvf <tar file> --xattrs warning/error in MLS enforcing
by Ted Toth
I'm going to simplify this because a lot of the detail isn't import to
the issue I'm working through. I'm taring some files, one of which
happens to be labeled SystemHigh and the rest SystemLow. An init
script, running SystemLow-SystemHigh, is later run on a different
system which untars the file. tar generates a warning message about
setfilecon failing for the file labeled SystemHigh and I see a
SELINUX_ERR message in the audit log (security_validate_transition:
denied for oldcontext=system_u:object_r:selinux_config_t:s0
newcontext=system_u:object_r:selinux_config_t:s15:c0-c1023
taskcontext=system_u:system_r:initrc_t=s0-s15:c0.c1023 tclass=file). I
am using run_init to run test this init script. What I'm confused
about is that there are no AVCs (I did an semnodule -DB just to see if
there were any dontaudits) and why there even is a failure as initrc_t
uses the mls_file_write_all_levels marco. Also does anyone know of a
way to see the contexts stored in the tar file?
Ted
13 years, 10 months
Help with messed up F11 SELinux
by Steve Blackwell
I've always had problems with SELinux but I set it to permissive and
moved on. Now I want to see if I can fix it.
My logwatch report gives me 20 or 30 lines of :
NULL security context for user, but SELinux in permissive mode,
continuing ()
in the cron section. Then I looked in /var/log/dmesg and I see this
line:
SELinux: 8 users, 12 roles, 2527 types, 119 bools, 1 sens, 1024 cats
System->Administration->SELinux Management, select SELinux User, shows
8 SELinux users:
guest_u,
root,
staff_u,
sysadm_u,
system_u,
unconfined_u,
user_u
xguest_u
OK, that looks good but when, as root, I run:
# semanage login -l
Login Name SELinux User MLS/MCS Range
__default__ unconfined_u s0-s0:c0.c1023
root unconfined_u s0-s0:c0.c1023
system_u system_u s0-s0:c0.c1023
hmmm... only 3 users. It this a problem or is it telling me that only 3
SELinuux users are currently in use (ie assign to any Linux user)
because I'm running in permissive mode?
How can I find out which user has a "NULL security context"?
Thanks,
Steve
13 years, 10 months
Policy prevents sendmail restarting
by Moray Henderson
We have an email configuration package that often needs to restart
sendmail when it is upgraded. To make updates as easy as possible for
the users, it has a trigger script on sendmail that contains
"/etc/rc.d/init.d/sendmail condrestart", so that they don't have to
remember to do that themselves.
This worked fine on CentOS 4. On CentOS 5 it has a problem:
# rpm -qa selinux\*
selinux-policy-targeted-2.4.6-255.el5_4.3
selinux-policy-2.4.6-255.el5_4.3
selinux-policy-devel-2.4.6-255.el5_4.3
Apr 29 12:40:27 ict sm-msp-queue[4024]: unable to write pid to
/var/run/sm-client.pid: Permission denied
time->Thu Apr 29 12:40:27 2010
type=SYSCALL msg=audit(1272541227.852:97659096): arch=40000003
syscall=196 success=no exit=-13 a0=bfec70d8 a1=bfec6f70 a2=4efff4 a3=3
items=0 ppid=4023 pid=4024 auid=783 uid=51 gid=51 euid=51 suid=51
fsuid=51 egid=51 sgid=51 fsgid=51 tty=(none) ses=23989 comm="sendmail"
exe="/usr/sbin/sendmail.sendmail" subj=user_u:system_r:system_mail_t:s0
key=(null)
type=AVC msg=audit(1272541227.852:97659096): avc: denied { getattr }
for pid=4024 comm="sendmail" path="/var/run/sm-client.pid" dev=dm-4
ino=1097779 scontext=user_u:system_r:system_mail_t:s0
tcontext=system_u:object_r:sendmail_var_run_t:s0 tclass=file
A manual restart of sendmail works. This is because of the following
transition rules:
type_transition unconfined_t sendmail_exec_t : process sendmail_t;
type_transition initrc_t sendmail_exec_t : process sendmail_t;
type_transition rpm_script_t sendmail_exec_t : process system_mail_t;
In other words, being run from an rpm script does not give sendmail
enough access to restart. I don't know why there wasn't a similar error
for /var/run/sendmail.pid, though.
Moray.
"To err is human. To purr, feline"
13 years, 10 months
porting a module from treysys refpolicy to debian
by Dennison Williams
Hello,
I am trying to port treysys' fail2ban.[te|fc]
(http://oss.tresys.com/repos/refpolicy/trunk/policy/modules/services/)
module to use on a debian system as a custom module and am having some
problems. I have built a custom module for this system, but I think
this case is slightly different because of calls to a few different
interfaces (that do exist on the system as installed via the
selinux-policy-refpolicy-dev package).
When I run:
# checkmodule -M -m -o fail2ban.mod fail2ban.te
checkmodule: loading policy configuration from fail2ban.te
(unknown source)::ERROR 'This block has no require section.' at
token 'init_daemon_domain' on line 10:
init_daemon_domain(fail2ban_t, fail2ban_exec_t)
type fail2ban_exec_t;
checkmodule: error(s) encountered while parsing configuration
This is obviously because I am not specifying the path to where the
init_daemon_domain interface is defined, but I am not sure how to do this.
I tried to add
require {
interface init_daemon_domain;
}
This does not seem to be the right way to do it either.
Any help is appreciated.
Sincerely,
Dennison Williams
13 years, 11 months
Fwd: Re: Help with messed up F11 SELinux
by Dominick Grift
On Mon, Apr 26, 2010 at 09:47:31AM -0400, Steve Blackwell wrote:
> On Mon, 26 Apr 2010 09:27:34 +0200
> Dominick Grift <domg472(a)gmail.com> wrote:
>
>
> > > > > [root@steve ~]# fixfiles
> > > > > restore ********************/sbin/setfiles: unable to stat
> > > > > file /home/steve/.gvfs: Permission denied
> > > > > /sbin/setfiles: error while labeling /: Permission
> > > > > denied
> > > > > /sbin/setfiles: error while labeling /boot: Permission
> > > > > denied
> > > > > /sbin/setfiles: error while
> > > > > labeling /media/blah-blah: Permission denied
> > > >
> > > > in /etc/selinux/config set "SELINUX=permissive"
> > > >
> > > > then do: touch /.autorelabel && reboot
> > > >
> > >
> > > OK, I did that and I still get these messages in /var/log/dmesg:
> >
> > If relabeling succeeded these issues should be fixed now.
> > You can check by listing: "ls -alZ /etc/rc.d/init.d/mysqld"
> >
> > if the type returned is mysqld_initrc_exec_t, then its fixed
> > if the type returned is unlabeled_t, then something went wrong.
>
> The type is mysqld_initrc_exec_t so it must be fixed.
> Things have definitely improved. I'm not getting streams of AVCs any
> more when I open the sevices GUI. Thnk you, Dominick!
>
> I do still have one (so far) problem though. When I tried to point my
> browser at my local BackupPC server page a get an "Unable to Connect"
> message and an AVC:
Yes selinux is still not playing nice with backuppc. I think the rpm of
backuppc includes a selinux policy
but i am not sure if that is installed by default.
I do know that this policy needs a lot of work, and in fact some time
ago i started creating a new policy for backuppc.
But i stumbled upon some packaging issues that i wanted resolved first
before i went ahead and complete the policy.
I never got to that point but i will consider revisiting backuppc policy.
I do still have my attempt for write policy for backuppc here:
git clone git://217.19.27.98/selinux-modules.git
But as said, it is incomplete.
>
> Raw Audit Messages :
> node=steve.blackwell type=AVC msg=audit(1272289200.98:138): avc: denied
> { write } for pid=31707 comm="perl5.10.0" name="BackupPC.sock" dev=dm-0
> ino=36667496 scontext=system_u:system_r:httpd_t:s0
> tcontext=system_u:object_r:var_log_t:s0 tclass=sock_file
>
> node=steve.blackwell type=SYSCALL msg=audit(1272289200.98:138):
> arch=40000003 syscall=102 success=no exit=-13 a0=3 a1=bfbd44e0
> a2=cfe4ac a3=9317008 items=0 ppid=2037 pid=31707 auid=4294967295 uid=48
> gid=48 euid=495 suid=495 fsuid=495 egid=48 sgid=48 fsgid=48 tty=(none)
> ses=4294967295 comm="perl5.10.0" exe="/usr/bin/perl5.10.0"
> subj=system_u:system_r:httpd_t:s0 key=(null)
>
> Now I know I could change the context of that socket file but I'm
> guessing that it gets created every time and so that is not a permanent
> solution. Is there a boolean I need to set; nothing looked obvious or
> perhaps a BackupPC policy I need to install?
>
> Thanks,
> Steve
13 years, 11 months
cgroup policy
by Dominick Grift
I implemented policy for the cgclear command that is part of the libcgroup suite.
You can find the extended cgroup module in my personal repository:
git://217.19.27.98/refpolicy.git
It is still permissive as it needs a bit more scrutiny.
13 years, 11 months
git policy
by Dominick Grift
I was browsing git policy and noticed this
optional_policy(`
apache_content_template(git)
- git_read_session_content_files(httpd_git_script_t)
+ git_read_all_content_files(httpd_git_script_t)
files_dontaudit_getattr_tmp_dirs(httpd_git_script_t)
')
Allow httpd git scripts to read git system and git user content. That way cgit or gitweb can display both: all system repositories in /var/lib/git as well as all user repositories in /home/*/public_git.
13 years, 11 months