selinux April 2010

selinux@lists.fedoraproject.org

31 participants
39 discussions

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

16 Aug '10

(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>

3 3

Apache/PHP mail function SELinux permissions
by Ted Rule 11 Jul '10

11 Jul '10

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/

3 5

Mod-security (mlogc) problem
by Arthur Dent 03 May '10

03 May '10

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)

5 42

tar xvf <tar file> --xattrs warning/error in MLS enforcing
by Ted Toth 03 May '10

03 May '10

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

2 2

Help with messed up F11 SELinux
by Steve Blackwell 29 Apr '10

29 Apr '10

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

4 25

Policy prevents sendmail restarting
by Moray Henderson 29 Apr '10

29 Apr '10

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"

2 2

porting a module from treysys refpolicy to debian
by Dennison Williams 26 Apr '10

26 Apr '10

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

2 1

Fwd: Re: Help with messed up F11 SELinux
by Dominick Grift 26 Apr '10

26 Apr '10

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

1 0

cgroup policy
by Dominick Grift 24 Apr '10

24 Apr '10

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.

1 0

git policy
by Dominick Grift 24 Apr '10

24 Apr '10

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.

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