From rchapman at aardvark.com.au Tue Sep 1 02:53:00 2009 From: rchapman at aardvark.com.au (Richard Chapman) Date: Tue, 01 Sep 2009 10:53:00 +0800 Subject: AVC every server boot: SELinux is preventing the setxkbmap from using potentially mislabeled files (./.X11-unix). In-Reply-To: <4A9BC6C0.8010600@redhat.com> References: <4A80C3E2.7090407@aardvark.com.au> <4A835607.6050102@aardvark.com.au> <4A84593C.8000407@redhat.com> <4A84E5C5.3000908@aardvark.com.au> <4A8557A2.403@redhat.com> <4A86420E.40200@aardvark.com.au> <4A8B1A43.6070300@redhat.com> <4A9B32B1.4030509@aardvark.com.au> <4A9BC6C0.8010600@redhat.com> Message-ID: <4A9C8C8C.6060806@aardvark.com.au> Daniel J Walsh wrote: > On 08/30/2009 10:17 PM, Richard Chapman wrote: > >> Hi Daniel >> >> FYI: I have just rebooted the system for the first time in ages - and >> I'm still using /tmp as opposes to tmpfs - and received 2 more AVCs - >> very similar to the previous ones. If I understood correctly - you were >> not expecting this to re-occur. I haven't posted the AVCs because I >> think they are much the same as the originals - but can do so if you are >> interested. >> >> This is not a major problem - but is one of the issues preventing me >> from using "enforcing" mode. Any thoughts why it has re-occurred? >> >> Richard. >> >> Daniel J Walsh wrote: >> >>> On 08/15/2009 01:05 AM, Richard Chapman wrote: >>> >>> >>>> Daniel J Walsh wrote: >>>> >>>> >>>>> On 08/14/2009 12:19 AM, Richard Chapman wrote: >>>>> >>>>> >>>>> >>>>>> Daniel J Walsh wrote: >>>>>> >>>>>> >>>>>>> On 08/12/2009 07:53 PM, Richard Chapman wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>>> I am running Centos 5.3 in permissive mode - and recently I started >>>>>>>> getting 4 avcs every time I boot the server. I am not sure - but I >>>>>>>> think >>>>>>>> these might have started when I changed my desktop from Gnome to >>>>>>>> KDE. I >>>>>>>> have tried the relabelling suggested in the AVC - but this hasn't >>>>>>>> fixed it. >>>>>>>> Does it look like I have something set up wrong - or is there a >>>>>>>> policy >>>>>>>> problem? >>>>>>>> Richard. >>>>>>>> >>>>>>>> >>>>>>>> Summary >>>>>>>> SELinux is preventing the setxkbmap from using potentially >>>>>>>> mislabeled >>>>>>>> files (./.X11-unix). >>>>>>>> Detailed Description >>>>>>>> [SELinux is in permissive mode, the operation would have been >>>>>>>> denied but >>>>>>>> was permitted due to permissive mode.] >>>>>>>> >>>>>>>> SELinux has denied setxkbmap access to potentially mislabeled >>>>>>>> file(s) >>>>>>>> (./.X11-unix). This means that SELinux will not allow setxkbmap >>>>>>>> to use >>>>>>>> these files. It is common for users to edit files in their home >>>>>>>> directory or tmp directories and then move (mv) them to system >>>>>>>> directories. The problem is that the files end up with the wrong >>>>>>>> file >>>>>>>> context which confined applications are not allowed to access. >>>>>>>> >>>>>>>> Allowing Access >>>>>>>> If you want setxkbmap to access this files, you need to relabel them >>>>>>>> using restorecon -v './.X11-unix'. You might want to relabel the >>>>>>>> entire >>>>>>>> directory using restorecon -R -v './.X11-unix'. >>>>>>>> Additional Information >>>>>>>> >>>>>>>> Source Context: system_u:system_r:rhgb_t >>>>>>>> Target Context: system_u:object_r:initrc_tmp_t >>>>>>>> Target Objects: ./.X11-unix [ dir ] >>>>>>>> Source: setxkbmap >>>>>>>> Source Path: /usr/bin/setxkbmap >>>>>>>> Port: >>>>>>>> Host: C5.aardvark.com.au >>>>>>>> Source RPM Packages: xorg-x11-xkb-utils-1.0.2-2.1 >>>>>>>> Target RPM Packages: Policy RPM: >>>>>>>> selinux-policy-2.4.6-225.el5 >>>>>>>> Selinux Enabled: True >>>>>>>> Policy Type: targeted >>>>>>>> MLS Enabled: True >>>>>>>> Enforcing Mode: Permissive >>>>>>>> Plugin Name: home_tmp_bad_labels >>>>>>>> Host Name: C5.aardvark.com.au >>>>>>>> Platform: Linux C5.aardvark.com.au 2.6.18-128.4.1.el5 #1 >>>>>>>> SMP Tue >>>>>>>> Aug 4 20:19:25 EDT 2009 x86_64 x86_64 >>>>>>>> Alert Count: 34 >>>>>>>> First Seen: Sun Jan 11 17:55:13 2009 >>>>>>>> Last Seen: Mon Aug 10 18:13:15 2009 >>>>>>>> Local ID: 0950df01-cfad-420a-9e84-4996a8d31942 >>>>>>>> Line Numbers: Raw Audit Messages : >>>>>>>> >>>>>>>> host=C5.aardvark.com.au type=AVC msg=audit(1249899195.897:15): avc: >>>>>>>> denied { search } for pid=4022 comm="setxkbmap" name=".X11-unix" >>>>>>>> dev=dm-0 ino=27590701 scontext=system_u:system_r:rhgb_t:s0 >>>>>>>> tcontext=system_u:object_r:initrc_tmp_t:s0 tclass=dir >>>>>>>> host=C5.aardvark.com.au type=AVC msg=audit(1249899195.897:15): avc: >>>>>>>> denied { search } for pid=4022 comm="setxkbmap" name=".X11-unix" >>>>>>>> dev=dm-0 ino=27590701 scontext=system_u:system_r:rhgb_t:s0 >>>>>>>> tcontext=system_u:object_r:initrc_tmp_t:s0 tclass=dir >>>>>>>> host=C5.aardvark.com.au type=SYSCALL msg=audit(1249899195.897:15): >>>>>>>> arch=c000003e syscall=42 success=no exit=-2 a0=3 a1=7fffd74235b0 >>>>>>>> a2=13 >>>>>>>> a3=3d29351a30 items=0 ppid=4021 pid=4022 auid=4294967295 uid=0 gid=0 >>>>>>>> euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) >>>>>>>> ses=4294967295 >>>>>>>> comm="setxkbmap" exe="/usr/bin/setxkbmap" >>>>>>>> subj=system_u:system_r:rhgb_t:s0 key=(null) >>>>>>>> host=C5.aardvark.com.au type=SYSCALL msg=audit(1249899195.897:15): >>>>>>>> arch=c000003e syscall=42 success=no exit=-2 a0=3 a1=7fffd74235b0 >>>>>>>> a2=13 >>>>>>>> a3=3d29351a30 items=0 ppid=4021 pid=4022 auid=4294967295 uid=0 gid=0 >>>>>>>> euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) >>>>>>>> ses=4294967295 >>>>>>>> comm="setxkbmap" exe="/usr/bin/setxkbmap" >>>>>>>> subj=system_u:system_r:rhgb_t:s0 key=(null) >>>>>>>> >>>>>>>> >>>>>>>> Summary >>>>>>>> SELinux is preventing the setxkbmap from using potentially >>>>>>>> mislabeled >>>>>>>> files (./.X11-unix). >>>>>>>> Detailed Description >>>>>>>> [SELinux is in permissive mode, the operation would have been >>>>>>>> denied but >>>>>>>> was permitted due to permissive mode.] >>>>>>>> >>>>>>>> SELinux has denied setxkbmap access to potentially mislabeled >>>>>>>> file(s) >>>>>>>> (./.X11-unix). This means that SELinux will not allow setxkbmap >>>>>>>> to use >>>>>>>> these files. It is common for users to edit files in their home >>>>>>>> directory or tmp directories and then move (mv) them to system >>>>>>>> directories. The problem is that the files end up with the wrong >>>>>>>> file >>>>>>>> context which confined applications are not allowed to access. >>>>>>>> >>>>>>>> Allowing Access >>>>>>>> If you want setxkbmap to access this files, you need to relabel them >>>>>>>> using restorecon -v './.X11-unix'. You might want to relabel the >>>>>>>> entire >>>>>>>> directory using restorecon -R -v './.X11-unix'. >>>>>>>> Additional Information >>>>>>>> >>>>>>>> Source Context: system_u:system_r:rhgb_t >>>>>>>> Target Context: system_u:object_r:initrc_tmp_t >>>>>>>> Target Objects: ./.X11-unix [ dir ] >>>>>>>> Source: setxkbmap >>>>>>>> Source Path: /usr/bin/setxkbmap >>>>>>>> Port: >>>>>>>> Host: C5.aardvark.com.au >>>>>>>> Source RPM Packages: xorg-x11-xkb-utils-1.0.2-2.1 >>>>>>>> Target RPM Packages: Policy RPM: >>>>>>>> selinux-policy-2.4.6-225.el5 >>>>>>>> Selinux Enabled: True >>>>>>>> Policy Type: targeted >>>>>>>> MLS Enabled: True >>>>>>>> Enforcing Mode: Permissive >>>>>>>> Plugin Name: home_tmp_bad_labels >>>>>>>> Host Name: C5.aardvark.com.au >>>>>>>> Platform: Linux C5.aardvark.com.au 2.6.18-128.4.1.el5 #1 >>>>>>>> SMP Tue >>>>>>>> Aug 4 20:19:25 EDT 2009 x86_64 x86_64 >>>>>>>> Alert Count: 35 >>>>>>>> First Seen: Sun Jan 11 17:55:13 2009 >>>>>>>> Last Seen: Mon Aug 10 18:13:16 2009 >>>>>>>> Local ID: 0950df01-cfad-420a-9e84-4996a8d31942 >>>>>>>> Line Numbers: Raw Audit Messages : >>>>>>>> >>>>>>>> host=C5.aardvark.com.au type=AVC msg=audit(1249899196.898:16): avc: >>>>>>>> denied { search } for pid=4022 comm="setxkbmap" name=".X11-unix" >>>>>>>> dev=dm-0 ino=27590701 scontext=system_u:system_r:rhgb_t:s0 >>>>>>>> tcontext=system_u:object_r:initrc_tmp_t:s0 tclass=dir >>>>>>>> host=C5.aardvark.com.au type=AVC msg=audit(1249899196.898:16): avc: >>>>>>>> denied { search } for pid=4022 comm="setxkbmap" name=".X11-unix" >>>>>>>> dev=dm-0 ino=27590701 scontext=system_u:system_r:rhgb_t:s0 >>>>>>>> tcontext=system_u:object_r:initrc_tmp_t:s0 tclass=dir >>>>>>>> host=C5.aardvark.com.au type=SYSCALL msg=audit(1249899196.898:16): >>>>>>>> arch=c000003e syscall=42 success=no exit=-2 a0=3 a1=7fffd74235b0 >>>>>>>> a2=13 >>>>>>>> a3=8 items=0 ppid=1 pid=4022 auid=4294967295 uid=0 gid=0 euid=0 >>>>>>>> suid=0 >>>>>>>> fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 >>>>>>>> comm="setxkbmap" >>>>>>>> exe="/usr/bin/setxkbmap" subj=system_u:system_r:rhgb_t:s0 key=(null) >>>>>>>> host=C5.aardvark.com.au type=SYSCALL msg=audit(1249899196.898:16): >>>>>>>> arch=c000003e syscall=42 success=no exit=-2 a0=3 a1=7fffd74235b0 >>>>>>>> a2=13 >>>>>>>> a3=8 items=0 ppid=1 pid=4022 auid=4294967295 uid=0 gid=0 euid=0 >>>>>>>> suid=0 >>>>>>>> fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 >>>>>>>> comm="setxkbmap" >>>>>>>> exe="/usr/bin/setxkbmap" subj=system_u:system_r:rhgb_t:s0 key=(null) >>>>>>>> >>>>>>>> >>>>>>>> Summary >>>>>>>> SELinux is preventing the setxkbmap from using potentially >>>>>>>> mislabeled >>>>>>>> files (./.X11-unix). >>>>>>>> Detailed Description >>>>>>>> [SELinux is in permissive mode, the operation would have been >>>>>>>> denied but >>>>>>>> was permitted due to permissive mode.] >>>>>>>> >>>>>>>> SELinux has denied setxkbmap access to potentially mislabeled >>>>>>>> file(s) >>>>>>>> (./.X11-unix). This means that SELinux will not allow setxkbmap >>>>>>>> to use >>>>>>>> these files. It is common for users to edit files in their home >>>>>>>> directory or tmp directories and then move (mv) them to system >>>>>>>> directories. The problem is that the files end up with the wrong >>>>>>>> file >>>>>>>> context which confined applications are not allowed to access. >>>>>>>> >>>>>>>> Allowing Access >>>>>>>> If you want setxkbmap to access this files, you need to relabel them >>>>>>>> using restorecon -v './.X11-unix'. You might want to relabel the >>>>>>>> entire >>>>>>>> directory using restorecon -R -v './.X11-unix'. >>>>>>>> Additional Information >>>>>>>> >>>>>>>> Source Context: system_u:system_r:rhgb_t >>>>>>>> Target Context: system_u:object_r:initrc_tmp_t >>>>>>>> Target Objects: ./.X11-unix [ dir ] >>>>>>>> Source: setxkbmap >>>>>>>> Source Path: /usr/bin/setxkbmap >>>>>>>> Port: >>>>>>>> Host: C5.aardvark.com.au >>>>>>>> Source RPM Packages: xorg-x11-xkb-utils-1.0.2-2.1 >>>>>>>> Target RPM Packages: Policy RPM: >>>>>>>> selinux-policy-2.4.6-225.el5 >>>>>>>> Selinux Enabled: True >>>>>>>> Policy Type: targeted >>>>>>>> MLS Enabled: True >>>>>>>> Enforcing Mode: Permissive >>>>>>>> Plugin Name: home_tmp_bad_labels >>>>>>>> Host Name: C5.aardvark.com.au >>>>>>>> Platform: Linux C5.aardvark.com.au 2.6.18-128.4.1.el5 #1 >>>>>>>> SMP Tue >>>>>>>> Aug 4 20:19:25 EDT 2009 x86_64 x86_64 >>>>>>>> Alert Count: 36 >>>>>>>> First Seen: Sun Jan 11 17:55:13 2009 >>>>>>>> Last Seen: Mon Aug 10 18:13:17 2009 >>>>>>>> Local ID: 0950df01-cfad-420a-9e84-4996a8d31942 >>>>>>>> Line Numbers: Raw Audit Messages : >>>>>>>> >>>>>>>> host=C5.aardvark.com.au type=AVC msg=audit(1249899197.933:18): avc: >>>>>>>> denied { search } for pid=4041 comm="setxkbmap" name=".X11-unix" >>>>>>>> dev=dm-0 ino=27590701 scontext=system_u:system_r:rhgb_t:s0 >>>>>>>> tcontext=system_u:object_r:initrc_tmp_t:s0 tclass=dir >>>>>>>> host=C5.aardvark.com.au type=AVC msg=audit(1249899197.933:18): avc: >>>>>>>> denied { search } for pid=4041 comm="setxkbmap" name=".X11-unix" >>>>>>>> dev=dm-0 ino=27590701 scontext=system_u:system_r:rhgb_t:s0 >>>>>>>> tcontext=system_u:object_r:initrc_tmp_t:s0 tclass=dir >>>>>>>> host=C5.aardvark.com.au type=SYSCALL msg=audit(1249899197.933:18): >>>>>>>> arch=c000003e syscall=42 success=no exit=-2 a0=3 a1=7fff31d13e20 >>>>>>>> a2=13 >>>>>>>> a3=8 items=0 ppid=1 pid=4041 auid=4294967295 uid=0 gid=0 euid=0 >>>>>>>> suid=0 >>>>>>>> fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 >>>>>>>> comm="setxkbmap" >>>>>>>> exe="/usr/bin/setxkbmap" subj=system_u:system_r:rhgb_t:s0 key=(null) >>>>>>>> host=C5.aardvark.com.au type=SYSCALL msg=audit(1249899197.933:18): >>>>>>>> arch=c000003e syscall=42 success=no exit=-2 a0=3 a1=7fff31d13e20 >>>>>>>> a2=13 >>>>>>>> a3=8 items=0 ppid=1 pid=4041 auid=4294967295 uid=0 gid=0 euid=0 >>>>>>>> suid=0 >>>>>>>> fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 >>>>>>>> comm="setxkbmap" >>>>>>>> exe="/usr/bin/setxkbmap" subj=system_u:system_r:rhgb_t:s0 key=(null) >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Summary >>>>>>>> SELinux is preventing the setxkbmap from using potentially >>>>>>>> mislabeled >>>>>>>> files (./.X11-unix). >>>>>>>> Detailed Description >>>>>>>> [SELinux is in permissive mode, the operation would have been >>>>>>>> denied but >>>>>>>> was permitted due to permissive mode.] >>>>>>>> >>>>>>>> SELinux has denied setxkbmap access to potentially mislabeled >>>>>>>> file(s) >>>>>>>> (./.X11-unix). This means that SELinux will not allow setxkbmap >>>>>>>> to use >>>>>>>> these files. It is common for users to edit files in their home >>>>>>>> directory or tmp directories and then move (mv) them to system >>>>>>>> directories. The problem is that the files end up with the wrong >>>>>>>> file >>>>>>>> context which confined applications are not allowed to access. >>>>>>>> >>>>>>>> Allowing Access >>>>>>>> If you want setxkbmap to access this files, you need to relabel them >>>>>>>> using restorecon -v './.X11-unix'. You might want to relabel the >>>>>>>> entire >>>>>>>> directory using restorecon -R -v './.X11-unix'. >>>>>>>> Additional Information >>>>>>>> >>>>>>>> Source Context: system_u:system_r:rhgb_t >>>>>>>> Target Context: system_u:object_r:initrc_tmp_t >>>>>>>> Target Objects: ./.X11-unix [ dir ] >>>>>>>> Source: setxkbmap >>>>>>>> Source Path: /usr/bin/setxkbmap >>>>>>>> Port: >>>>>>>> Host: C5.aardvark.com.au >>>>>>>> Source RPM Packages: xorg-x11-xkb-utils-1.0.2-2.1 >>>>>>>> Target RPM Packages: Policy RPM: >>>>>>>> selinux-policy-2.4.6-225.el5 >>>>>>>> Selinux Enabled: True >>>>>>>> Policy Type: targeted >>>>>>>> MLS Enabled: True >>>>>>>> Enforcing Mode: Permissive >>>>>>>> Plugin Name: home_tmp_bad_labels >>>>>>>> Host Name: C5.aardvark.com.au >>>>>>>> Platform: Linux C5.aardvark.com.au 2.6.18-128.4.1.el5 #1 >>>>>>>> SMP Tue >>>>>>>> Aug 4 20:19:25 EDT 2009 x86_64 x86_64 >>>>>>>> Alert Count: 37 >>>>>>>> First Seen: Sun Jan 11 17:55:13 2009 >>>>>>>> Last Seen: Mon Aug 10 18:13:19 2009 >>>>>>>> Local ID: 0950df01-cfad-420a-9e84-4996a8d31942 >>>>>>>> Line Numbers: Raw Audit Messages : >>>>>>>> >>>>>>>> host=C5.aardvark.com.au type=AVC msg=audit(1249899199.903:20): avc: >>>>>>>> denied { search } for pid=4022 comm="setxkbmap" name=".X11-unix" >>>>>>>> dev=dm-0 ino=27590701 scontext=system_u:system_r:rhgb_t:s0 >>>>>>>> tcontext=system_u:object_r:initrc_tmp_t:s0 tclass=dir >>>>>>>> host=C5.aardvark.com.au type=AVC msg=audit(1249899199.903:20): avc: >>>>>>>> denied { search } for pid=4022 comm="setxkbmap" name=".X11-unix" >>>>>>>> dev=dm-0 ino=27590701 scontext=system_u:system_r:rhgb_t:s0 >>>>>>>> tcontext=system_u:object_r:initrc_tmp_t:s0 tclass=dir >>>>>>>> host=C5.aardvark.com.au type=SYSCALL msg=audit(1249899199.903:20): >>>>>>>> arch=c000003e syscall=42 success=no exit=-2 a0=3 a1=7fffd74235b0 >>>>>>>> a2=13 >>>>>>>> a3=8 items=0 ppid=1 pid=4022 auid=4294967295 uid=0 gid=0 euid=0 >>>>>>>> suid=0 >>>>>>>> fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 >>>>>>>> comm="setxkbmap" >>>>>>>> exe="/usr/bin/setxkbmap" subj=system_u:system_r:rhgb_t:s0 key=(null) >>>>>>>> host=C5.aardvark.com.au type=SYSCALL msg=audit(1249899199.903:20): >>>>>>>> arch=c000003e syscall=42 success=no exit=-2 a0=3 a1=7fffd74235b0 >>>>>>>> a2=13 >>>>>>>> a3=8 items=0 ppid=1 pid=4022 auid=4294967295 uid=0 gid=0 euid=0 >>>>>>>> suid=0 >>>>>>>> fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 >>>>>>>> comm="setxkbmap" >>>>>>>> exe="/usr/bin/setxkbmap" subj=system_u:system_r:rhgb_t:s0 key=(null) >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> fedora-selinux-list mailing list >>>>>>>> fedora-selinux-list at redhat.com >>>>>>>> https://www.redhat.com/mailman/listinfo/fedora-selinux-list >>>>>>>> >>>>>>>> >>>>>>> chcon -R -t xserver_tmp_t /tmp/.X11-unix >>>>>>> >>>>>>> I always use tmpfs for /tmp, so I never end up with garbage on a >>>>>>> reboot. >>>>>>> >>>>>>> >>>>>>> >>>>>> Thanks Daniel - but this is the response... >>>>>> >>>>>> [root at C5 ~]# chcon -R -t xserver_tmp_t /tmp/.X11-unix >>>>>> chcon: failed to change context of /tmp/.X11-unix to >>>>>> system_u:object_r:xserver_t mp_t: Invalid >>>>>> argument >>>>>> chcon: failed to change context of /tmp/.X11-unix/X0 to >>>>>> system_u:object_r:xserve r_tmp_t: Invalid >>>>>> argument >>>>>> chcon: failed to change context of /tmp/.X11-unix/X1005 to >>>>>> user_u:object_r:xserv er_tmp_t: Invalid >>>>>> argument >>>>>> [root at C5 ~]# >>>>>> >>>>>> Being pretty green - I don't really understand the problem here. >>>>>> Also - >>>>>> if this chcon worked - would this be a permanent solution - or does it >>>>>> need to be executed in a boot script? >>>>>> I like your idea of using tmpfs - but is it ever a problem that >>>>>> tmpfs is >>>>>> relatively small and finite? Also - please excuse my ignorance - >>>>>> but how >>>>>> do I make tmpfs the tmp folder? >>>>>> >>>>>> Richard. >>>>>> >>>>>> >>>>>> >>>>>> >>>>> Must have changed between RHEL5 and F11 >>>>> >>>>> Try >>>>> chcon -R -t xdm_xserver_tmp_t /tmp/.X11-unix >>>>> >>>>> Add this line to /etc/fstab >>>>> >>>>> tmpfs /tmp tmpfs >>>>> rootcontext="system_u:object_r:tmp_t:s0",defaults 0 0 >>>>> >>>>> And reboot. >>>>> >>>>> I don't tend to store huge abouts of stuff in /tmp. If I want to >>>>> store big stuff I can always use /var/tmp >>>>> >>>>> >>>>> >>>> Thanks Daniel >>>> >>>> That chcon command worked fine. Should this be a permanent solution - or >>>> will new files appearing there need a chcon too? Should I put this >>>> command into a boot script somewhere? >>>> >>>> I'll try tmpfs and see if it ever overflows in practice. Hopefully I'll >>>> be able to see something in my logwatch if there is ever a problem. >>>> Currently - It's using less than 1/2 its 2 gigs or ram - so there is >>>> some room to spare. Seems your suggestion has sparked quite a bit of >>>> interest...:-) >>>> >>>> Thanks again >>>> >>>> Richard. >>>> >>>> >>>> >>>> >>> No the chcon is fine. It was mislabeled at some point and relabeling >>> does not touch /tmp >>> >>> >>> > > I guess I would need to see the AVC messages, to make sure they are the same. > > What is the label on the /tmp/.X11-unix directory? > > Hi Daniel Does this answer your question? *> ls -Za /tmp* drwxrwxrwt root root system_u:object_r:tmp_t . drwxr-xr-x root root system_u:object_r:root_t .. drwxrwxrwt root root system_u:object_r:xdm_tmp_t .ICE-unix -r--r--r-- root root system_u:object_r:xdm_tmp_t .X0-lock drwxrwxrwt root root system_u:object_r:initrc_tmp_t .X11-unix drwxrwxrwt root root system_u:object_r:xfs_tmp_t .font-unix srw-rw-rw- root root system_u:object_r:xdm_tmp_t .gdm_socket -rw------- nx nx user_u:object_r:tmp_t .nX1000-lock drwxr-xr-x root root root:object_r:initrc_tmp_t .webmin drwx------ root root user_u:object_r:tmp_t gconfd-root srwxr-xr-x root root user_u:object_r:tmp_t gedit.root.3537314166 srwxr-xr-x root root user_u:object_r:tmp_t mapping-root -rw-r--r-- root root user_u:object_r:tmp_t sarg-file.in And just in case it is useful: *> ls -Za /tmp/.X11-unix* drwxrwxrwt root root system_u:object_r:initrc_tmp_t . drwxrwxrwt root root system_u:object_r:tmp_t .. srwxrwxrwx root root system_u:object_r:initrc_tmp_t X0 Here are the recent AVCs: Summary SELinux is preventing the setxkbmap from using potentially mislabeled files (./.X11-unix). Detailed Description [SELinux is in permissive mode, the operation would have been denied but was permitted due to permissive mode.] SELinux has denied setxkbmap access to potentially mislabeled file(s) (./.X11-unix). This means that SELinux will not allow setxkbmap to use these files. It is common for users to edit files in their home directory or tmp directories and then move (mv) them to system directories. The problem is that the files end up with the wrong file context which confined applications are not allowed to access. Allowing Access If you want setxkbmap to access this files, you need to relabel them using restorecon -v './.X11-unix'. You might want to relabel the entire directory using restorecon -R -v './.X11-unix'. Additional Information Source Context: system_u:system_r:rhgb_t Target Context: system_u:object_r:initrc_tmp_t Target Objects: ./.X11-unix [ dir ] Source: setxkbmap Source Path: /usr/bin/setxkbmap Port: Host: C5.aardvark.com.au Source RPM Packages: xorg-x11-xkb-utils-1.0.2-2.1 Target RPM Packages: Policy RPM: selinux-policy-2.4.6-225.el5 Selinux Enabled: True Policy Type: targeted MLS Enabled: True Enforcing Mode: Permissive Plugin Name: home_tmp_bad_labels Host Name: C5.aardvark.com.au Platform: Linux C5.aardvark.com.au 2.6.18-128.7.1.el5 #1 SMP Mon Aug 24 08:21:56 EDT 2009 x86_64 x86_64 Alert Count: 38 First Seen: Sun Jan 11 17:55:13 2009 Last Seen: Mon Aug 31 09:24:11 2009 Local ID: 0950df01-cfad-420a-9e84-4996a8d31942 Line Numbers: Raw Audit Messages : host=C5.aardvark.com.au type=AVC msg=audit(1251681851.968:15): avc: denied { search } for pid=4135 comm="setxkbmap" name=".X11-unix" dev=dm-0 ino=27590701 scontext=system_u:system_r:rhgb_t:s0 tcontext=system_u:object_r:initrc_tmp_t:s0 tclass=dir host=C5.aardvark.com.au type=AVC msg=audit(1251681851.968:15): avc: denied { search } for pid=4135 comm="setxkbmap" name=".X11-unix" dev=dm-0 ino=27590701 scontext=system_u:system_r:rhgb_t:s0 tcontext=system_u:object_r:initrc_tmp_t:s0 tclass=dir host=C5.aardvark.com.au type=SYSCALL msg=audit(1251681851.968:15): arch=c000003e syscall=42 success=no exit=-2 a0=3 a1=7fff95f931b0 a2=13 a3=0 items=0 ppid=1 pid=4135 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="setxkbmap" exe="/usr/bin/setxkbmap" subj=system_u:system_r:rhgb_t:s0 key=(null) host=C5.aardvark.com.au type=SYSCALL msg=audit(1251681851.968:15): arch=c000003e syscall=42 success=no exit=-2 a0=3 a1=7fff95f931b0 a2=13 a3=0 items=0 ppid=1 pid=4135 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="setxkbmap" exe="/usr/bin/setxkbmap" subj=system_u:system_r:rhgb_t:s0 key=(null) Summary SELinux is preventing the setxkbmap from using potentially mislabeled files (./.X11-unix). Detailed Description [SELinux is in permissive mode, the operation would have been denied but was permitted due to permissive mode.] SELinux has denied setxkbmap access to potentially mislabeled file(s) (./.X11-unix). This means that SELinux will not allow setxkbmap to use these files. It is common for users to edit files in their home directory or tmp directories and then move (mv) them to system directories. The problem is that the files end up with the wrong file context which confined applications are not allowed to access. Allowing Access If you want setxkbmap to access this files, you need to relabel them using restorecon -v './.X11-unix'. You might want to relabel the entire directory using restorecon -R -v './.X11-unix'. Additional Information Source Context: system_u:system_r:rhgb_t Target Context: system_u:object_r:initrc_tmp_t Target Objects: ./.X11-unix [ dir ] Source: setxkbmap Source Path: /usr/bin/setxkbmap Port: Host: C5.aardvark.com.au Source RPM Packages: xorg-x11-xkb-utils-1.0.2-2.1 Target RPM Packages: Policy RPM: selinux-policy-2.4.6-225.el5 Selinux Enabled: True Policy Type: targeted MLS Enabled: True Enforcing Mode: Permissive Plugin Name: home_tmp_bad_labels Host Name: C5.aardvark.com.au Platform: Linux C5.aardvark.com.au 2.6.18-128.7.1.el5 #1 SMP Mon Aug 24 08:21:56 EDT 2009 x86_64 x86_64 Alert Count: 39 First Seen: Sun Jan 11 17:55:13 2009 Last Seen: Mon Aug 31 09:24:13 2009 Local ID: 0950df01-cfad-420a-9e84-4996a8d31942 Line Numbers: Raw Audit Messages : host=C5.aardvark.com.au type=AVC msg=audit(1251681853.972:16): avc: denied { search } for pid=4135 comm="setxkbmap" name=".X11-unix" dev=dm-0 ino=27590701 scontext=system_u:system_r:rhgb_t:s0 tcontext=system_u:object_r:initrc_tmp_t:s0 tclass=dir host=C5.aardvark.com.au type=AVC msg=audit(1251681853.972:16): avc: denied { search } for pid=4135 comm="setxkbmap" name=".X11-unix" dev=dm-0 ino=27590701 scontext=system_u:system_r:rhgb_t:s0 tcontext=system_u:object_r:initrc_tmp_t:s0 tclass=dir host=C5.aardvark.com.au type=SYSCALL msg=audit(1251681853.972:16): arch=c000003e syscall=42 success=no exit=-2 a0=3 a1=7fff95f931b0 a2=13 a3=8 items=0 ppid=1 pid=4135 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="setxkbmap" exe="/usr/bin/setxkbmap" subj=system_u:system_r:rhgb_t:s0 key=(null) host=C5.aardvark.com.au type=SYSCALL msg=audit(1251681853.972:16): arch=c000003e syscall=42 success=no exit=-2 a0=3 a1=7fff95f931b0 a2=13 a3=8 items=0 ppid=1 pid=4135 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="setxkbmap" exe="/usr/bin/setxkbmap" subj=system_u:system_r:rhgb_t:s0 key=(null) From dwalsh at redhat.com Tue Sep 1 12:21:08 2009 From: dwalsh at redhat.com (Daniel J Walsh) Date: Tue, 01 Sep 2009 08:21:08 -0400 Subject: AVC every server boot: SELinux is preventing the setxkbmap from using potentially mislabeled files (./.X11-unix). In-Reply-To: <4A9C8C8C.6060806@aardvark.com.au> References: <4A80C3E2.7090407@aardvark.com.au> <4A835607.6050102@aardvark.com.au> <4A84593C.8000407@redhat.com> <4A84E5C5.3000908@aardvark.com.au> <4A8557A2.403@redhat.com> <4A86420E.40200@aardvark.com.au> <4A8B1A43.6070300@redhat.com> <4A9B32B1.4030509@aardvark.com.au> <4A9BC6C0.8010600@redhat.com> <4A9C8C8C.6060806@aardvark.com.au> Message-ID: <4A9D11B4.4070703@redhat.com> On 08/31/2009 10:53 PM, Richard Chapman wrote: > Daniel J Walsh wrote: >> On 08/30/2009 10:17 PM, Richard Chapman wrote: >> >>> Hi Daniel >>> >>> FYI: I have just rebooted the system for the first time in ages - and >>> I'm still using /tmp as opposes to tmpfs - and received 2 more AVCs - >>> very similar to the previous ones. If I understood correctly - you were >>> not expecting this to re-occur. I haven't posted the AVCs because I >>> think they are much the same as the originals - but can do so if you are >>> interested. >>> >>> This is not a major problem - but is one of the issues preventing me >>> from using "enforcing" mode. Any thoughts why it has re-occurred? >>> >>> Richard. >>> >>> Daniel J Walsh wrote: >>> >>>> On 08/15/2009 01:05 AM, Richard Chapman wrote: >>>> >>>> >>>>> Daniel J Walsh wrote: >>>>> >>>>>> On 08/14/2009 12:19 AM, Richard Chapman wrote: >>>>>> >>>>>> >>>>>>> Daniel J Walsh wrote: >>>>>>> >>>>>>>> On 08/12/2009 07:53 PM, Richard Chapman wrote: >>>>>>>> >>>>>>>> >>>>>>>>> I am running Centos 5.3 in permissive mode - and recently I >>>>>>>>> started >>>>>>>>> getting 4 avcs every time I boot the server. I am not sure - but I >>>>>>>>> think >>>>>>>>> these might have started when I changed my desktop from Gnome to >>>>>>>>> KDE. I >>>>>>>>> have tried the relabelling suggested in the AVC - but this hasn't >>>>>>>>> fixed it. >>>>>>>>> Does it look like I have something set up wrong - or is there a >>>>>>>>> policy >>>>>>>>> problem? >>>>>>>>> Richard. >>>>>>>>> >>>>>>>>> >>>>>>>>> Summary >>>>>>>>> SELinux is preventing the setxkbmap from using potentially >>>>>>>>> mislabeled >>>>>>>>> files (./.X11-unix). >>>>>>>>> Detailed Description >>>>>>>>> [SELinux is in permissive mode, the operation would have been >>>>>>>>> denied but >>>>>>>>> was permitted due to permissive mode.] >>>>>>>>> >>>>>>>>> SELinux has denied setxkbmap access to potentially mislabeled >>>>>>>>> file(s) >>>>>>>>> (./.X11-unix). This means that SELinux will not allow setxkbmap >>>>>>>>> to use >>>>>>>>> these files. It is common for users to edit files in their home >>>>>>>>> directory or tmp directories and then move (mv) them to system >>>>>>>>> directories. The problem is that the files end up with the wrong >>>>>>>>> file >>>>>>>>> context which confined applications are not allowed to access. >>>>>>>>> >>>>>>>>> Allowing Access >>>>>>>>> If you want setxkbmap to access this files, you need to relabel >>>>>>>>> them >>>>>>>>> using restorecon -v './.X11-unix'. You might want to relabel the >>>>>>>>> entire >>>>>>>>> directory using restorecon -R -v './.X11-unix'. >>>>>>>>> Additional Information >>>>>>>>> >>>>>>>>> Source Context: system_u:system_r:rhgb_t >>>>>>>>> Target Context: system_u:object_r:initrc_tmp_t >>>>>>>>> Target Objects: ./.X11-unix [ dir ] >>>>>>>>> Source: setxkbmap >>>>>>>>> Source Path: /usr/bin/setxkbmap >>>>>>>>> Port: >>>>>>>>> Host: C5.aardvark.com.au >>>>>>>>> Source RPM Packages: xorg-x11-xkb-utils-1.0.2-2.1 >>>>>>>>> Target RPM Packages: Policy RPM: >>>>>>>>> selinux-policy-2.4.6-225.el5 >>>>>>>>> Selinux Enabled: True >>>>>>>>> Policy Type: targeted >>>>>>>>> MLS Enabled: True >>>>>>>>> Enforcing Mode: Permissive >>>>>>>>> Plugin Name: home_tmp_bad_labels >>>>>>>>> Host Name: C5.aardvark.com.au >>>>>>>>> Platform: Linux C5.aardvark.com.au 2.6.18-128.4.1.el5 #1 >>>>>>>>> SMP Tue >>>>>>>>> Aug 4 20:19:25 EDT 2009 x86_64 x86_64 >>>>>>>>> Alert Count: 34 >>>>>>>>> First Seen: Sun Jan 11 17:55:13 2009 >>>>>>>>> Last Seen: Mon Aug 10 18:13:15 2009 >>>>>>>>> Local ID: 0950df01-cfad-420a-9e84-4996a8d31942 >>>>>>>>> Line Numbers: Raw Audit Messages : >>>>>>>>> >>>>>>>>> host=C5.aardvark.com.au type=AVC msg=audit(1249899195.897:15): >>>>>>>>> avc: >>>>>>>>> denied { search } for pid=4022 comm="setxkbmap" name=".X11-unix" >>>>>>>>> dev=dm-0 ino=27590701 scontext=system_u:system_r:rhgb_t:s0 >>>>>>>>> tcontext=system_u:object_r:initrc_tmp_t:s0 tclass=dir >>>>>>>>> host=C5.aardvark.com.au type=AVC msg=audit(1249899195.897:15): >>>>>>>>> avc: >>>>>>>>> denied { search } for pid=4022 comm="setxkbmap" name=".X11-unix" >>>>>>>>> dev=dm-0 ino=27590701 scontext=system_u:system_r:rhgb_t:s0 >>>>>>>>> tcontext=system_u:object_r:initrc_tmp_t:s0 tclass=dir >>>>>>>>> host=C5.aardvark.com.au type=SYSCALL msg=audit(1249899195.897:15): >>>>>>>>> arch=c000003e syscall=42 success=no exit=-2 a0=3 a1=7fffd74235b0 >>>>>>>>> a2=13 >>>>>>>>> a3=3d29351a30 items=0 ppid=4021 pid=4022 auid=4294967295 uid=0 >>>>>>>>> gid=0 >>>>>>>>> euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) >>>>>>>>> ses=4294967295 >>>>>>>>> comm="setxkbmap" exe="/usr/bin/setxkbmap" >>>>>>>>> subj=system_u:system_r:rhgb_t:s0 key=(null) >>>>>>>>> host=C5.aardvark.com.au type=SYSCALL msg=audit(1249899195.897:15): >>>>>>>>> arch=c000003e syscall=42 success=no exit=-2 a0=3 a1=7fffd74235b0 >>>>>>>>> a2=13 >>>>>>>>> a3=3d29351a30 items=0 ppid=4021 pid=4022 auid=4294967295 uid=0 >>>>>>>>> gid=0 >>>>>>>>> euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) >>>>>>>>> ses=4294967295 >>>>>>>>> comm="setxkbmap" exe="/usr/bin/setxkbmap" >>>>>>>>> subj=system_u:system_r:rhgb_t:s0 key=(null) >>>>>>>>> >>>>>>>>> >>>>>>>>> Summary >>>>>>>>> SELinux is preventing the setxkbmap from using potentially >>>>>>>>> mislabeled >>>>>>>>> files (./.X11-unix). >>>>>>>>> Detailed Description >>>>>>>>> [SELinux is in permissive mode, the operation would have been >>>>>>>>> denied but >>>>>>>>> was permitted due to permissive mode.] >>>>>>>>> >>>>>>>>> SELinux has denied setxkbmap access to potentially mislabeled >>>>>>>>> file(s) >>>>>>>>> (./.X11-unix). This means that SELinux will not allow setxkbmap >>>>>>>>> to use >>>>>>>>> these files. It is common for users to edit files in their home >>>>>>>>> directory or tmp directories and then move (mv) them to system >>>>>>>>> directories. The problem is that the files end up with the wrong >>>>>>>>> file >>>>>>>>> context which confined applications are not allowed to access. >>>>>>>>> >>>>>>>>> Allowing Access >>>>>>>>> If you want setxkbmap to access this files, you need to relabel >>>>>>>>> them >>>>>>>>> using restorecon -v './.X11-unix'. You might want to relabel the >>>>>>>>> entire >>>>>>>>> directory using restorecon -R -v './.X11-unix'. >>>>>>>>> Additional Information >>>>>>>>> >>>>>>>>> Source Context: system_u:system_r:rhgb_t >>>>>>>>> Target Context: system_u:object_r:initrc_tmp_t >>>>>>>>> Target Objects: ./.X11-unix [ dir ] >>>>>>>>> Source: setxkbmap >>>>>>>>> Source Path: /usr/bin/setxkbmap >>>>>>>>> Port: >>>>>>>>> Host: C5.aardvark.com.au >>>>>>>>> Source RPM Packages: xorg-x11-xkb-utils-1.0.2-2.1 >>>>>>>>> Target RPM Packages: Policy RPM: >>>>>>>>> selinux-policy-2.4.6-225.el5 >>>>>>>>> Selinux Enabled: True >>>>>>>>> Policy Type: targeted >>>>>>>>> MLS Enabled: True >>>>>>>>> Enforcing Mode: Permissive >>>>>>>>> Plugin Name: home_tmp_bad_labels >>>>>>>>> Host Name: C5.aardvark.com.au >>>>>>>>> Platform: Linux C5.aardvark.com.au 2.6.18-128.4.1.el5 #1 >>>>>>>>> SMP Tue >>>>>>>>> Aug 4 20:19:25 EDT 2009 x86_64 x86_64 >>>>>>>>> Alert Count: 35 >>>>>>>>> First Seen: Sun Jan 11 17:55:13 2009 >>>>>>>>> Last Seen: Mon Aug 10 18:13:16 2009 >>>>>>>>> Local ID: 0950df01-cfad-420a-9e84-4996a8d31942 >>>>>>>>> Line Numbers: Raw Audit Messages : >>>>>>>>> >>>>>>>>> host=C5.aardvark.com.au type=AVC msg=audit(1249899196.898:16): >>>>>>>>> avc: >>>>>>>>> denied { search } for pid=4022 comm="setxkbmap" name=".X11-unix" >>>>>>>>> dev=dm-0 ino=27590701 scontext=system_u:system_r:rhgb_t:s0 >>>>>>>>> tcontext=system_u:object_r:initrc_tmp_t:s0 tclass=dir >>>>>>>>> host=C5.aardvark.com.au type=AVC msg=audit(1249899196.898:16): >>>>>>>>> avc: >>>>>>>>> denied { search } for pid=4022 comm="setxkbmap" name=".X11-unix" >>>>>>>>> dev=dm-0 ino=27590701 scontext=system_u:system_r:rhgb_t:s0 >>>>>>>>> tcontext=system_u:object_r:initrc_tmp_t:s0 tclass=dir >>>>>>>>> host=C5.aardvark.com.au type=SYSCALL msg=audit(1249899196.898:16): >>>>>>>>> arch=c000003e syscall=42 success=no exit=-2 a0=3 a1=7fffd74235b0 >>>>>>>>> a2=13 >>>>>>>>> a3=8 items=0 ppid=1 pid=4022 auid=4294967295 uid=0 gid=0 euid=0 >>>>>>>>> suid=0 >>>>>>>>> fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 >>>>>>>>> comm="setxkbmap" >>>>>>>>> exe="/usr/bin/setxkbmap" subj=system_u:system_r:rhgb_t:s0 >>>>>>>>> key=(null) >>>>>>>>> host=C5.aardvark.com.au type=SYSCALL msg=audit(1249899196.898:16): >>>>>>>>> arch=c000003e syscall=42 success=no exit=-2 a0=3 a1=7fffd74235b0 >>>>>>>>> a2=13 >>>>>>>>> a3=8 items=0 ppid=1 pid=4022 auid=4294967295 uid=0 gid=0 euid=0 >>>>>>>>> suid=0 >>>>>>>>> fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 >>>>>>>>> comm="setxkbmap" >>>>>>>>> exe="/usr/bin/setxkbmap" subj=system_u:system_r:rhgb_t:s0 >>>>>>>>> key=(null) >>>>>>>>> >>>>>>>>> >>>>>>>>> Summary >>>>>>>>> SELinux is preventing the setxkbmap from using potentially >>>>>>>>> mislabeled >>>>>>>>> files (./.X11-unix). >>>>>>>>> Detailed Description >>>>>>>>> [SELinux is in permissive mode, the operation would have been >>>>>>>>> denied but >>>>>>>>> was permitted due to permissive mode.] >>>>>>>>> >>>>>>>>> SELinux has denied setxkbmap access to potentially mislabeled >>>>>>>>> file(s) >>>>>>>>> (./.X11-unix). This means that SELinux will not allow setxkbmap >>>>>>>>> to use >>>>>>>>> these files. It is common for users to edit files in their home >>>>>>>>> directory or tmp directories and then move (mv) them to system >>>>>>>>> directories. The problem is that the files end up with the wrong >>>>>>>>> file >>>>>>>>> context which confined applications are not allowed to access. >>>>>>>>> >>>>>>>>> Allowing Access >>>>>>>>> If you want setxkbmap to access this files, you need to relabel >>>>>>>>> them >>>>>>>>> using restorecon -v './.X11-unix'. You might want to relabel the >>>>>>>>> entire >>>>>>>>> directory using restorecon -R -v './.X11-unix'. >>>>>>>>> Additional Information >>>>>>>>> >>>>>>>>> Source Context: system_u:system_r:rhgb_t >>>>>>>>> Target Context: system_u:object_r:initrc_tmp_t >>>>>>>>> Target Objects: ./.X11-unix [ dir ] >>>>>>>>> Source: setxkbmap >>>>>>>>> Source Path: /usr/bin/setxkbmap >>>>>>>>> Port: >>>>>>>>> Host: C5.aardvark.com.au >>>>>>>>> Source RPM Packages: xorg-x11-xkb-utils-1.0.2-2.1 >>>>>>>>> Target RPM Packages: Policy RPM: >>>>>>>>> selinux-policy-2.4.6-225.el5 >>>>>>>>> Selinux Enabled: True >>>>>>>>> Policy Type: targeted >>>>>>>>> MLS Enabled: True >>>>>>>>> Enforcing Mode: Permissive >>>>>>>>> Plugin Name: home_tmp_bad_labels >>>>>>>>> Host Name: C5.aardvark.com.au >>>>>>>>> Platform: Linux C5.aardvark.com.au 2.6.18-128.4.1.el5 #1 >>>>>>>>> SMP Tue >>>>>>>>> Aug 4 20:19:25 EDT 2009 x86_64 x86_64 >>>>>>>>> Alert Count: 36 >>>>>>>>> First Seen: Sun Jan 11 17:55:13 2009 >>>>>>>>> Last Seen: Mon Aug 10 18:13:17 2009 >>>>>>>>> Local ID: 0950df01-cfad-420a-9e84-4996a8d31942 >>>>>>>>> Line Numbers: Raw Audit Messages : >>>>>>>>> >>>>>>>>> host=C5.aardvark.com.au type=AVC msg=audit(1249899197.933:18): >>>>>>>>> avc: >>>>>>>>> denied { search } for pid=4041 comm="setxkbmap" name=".X11-unix" >>>>>>>>> dev=dm-0 ino=27590701 scontext=system_u:system_r:rhgb_t:s0 >>>>>>>>> tcontext=system_u:object_r:initrc_tmp_t:s0 tclass=dir >>>>>>>>> host=C5.aardvark.com.au type=AVC msg=audit(1249899197.933:18): >>>>>>>>> avc: >>>>>>>>> denied { search } for pid=4041 comm="setxkbmap" name=".X11-unix" >>>>>>>>> dev=dm-0 ino=27590701 scontext=system_u:system_r:rhgb_t:s0 >>>>>>>>> tcontext=system_u:object_r:initrc_tmp_t:s0 tclass=dir >>>>>>>>> host=C5.aardvark.com.au type=SYSCALL msg=audit(1249899197.933:18): >>>>>>>>> arch=c000003e syscall=42 success=no exit=-2 a0=3 a1=7fff31d13e20 >>>>>>>>> a2=13 >>>>>>>>> a3=8 items=0 ppid=1 pid=4041 auid=4294967295 uid=0 gid=0 euid=0 >>>>>>>>> suid=0 >>>>>>>>> fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 >>>>>>>>> comm="setxkbmap" >>>>>>>>> exe="/usr/bin/setxkbmap" subj=system_u:system_r:rhgb_t:s0 >>>>>>>>> key=(null) >>>>>>>>> host=C5.aardvark.com.au type=SYSCALL msg=audit(1249899197.933:18): >>>>>>>>> arch=c000003e syscall=42 success=no exit=-2 a0=3 a1=7fff31d13e20 >>>>>>>>> a2=13 >>>>>>>>> a3=8 items=0 ppid=1 pid=4041 auid=4294967295 uid=0 gid=0 euid=0 >>>>>>>>> suid=0 >>>>>>>>> fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 >>>>>>>>> comm="setxkbmap" >>>>>>>>> exe="/usr/bin/setxkbmap" subj=system_u:system_r:rhgb_t:s0 >>>>>>>>> key=(null) >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Summary >>>>>>>>> SELinux is preventing the setxkbmap from using potentially >>>>>>>>> mislabeled >>>>>>>>> files (./.X11-unix). >>>>>>>>> Detailed Description >>>>>>>>> [SELinux is in permissive mode, the operation would have been >>>>>>>>> denied but >>>>>>>>> was permitted due to permissive mode.] >>>>>>>>> >>>>>>>>> SELinux has denied setxkbmap access to potentially mislabeled >>>>>>>>> file(s) >>>>>>>>> (./.X11-unix). This means that SELinux will not allow setxkbmap >>>>>>>>> to use >>>>>>>>> these files. It is common for users to edit files in their home >>>>>>>>> directory or tmp directories and then move (mv) them to system >>>>>>>>> directories. The problem is that the files end up with the wrong >>>>>>>>> file >>>>>>>>> context which confined applications are not allowed to access. >>>>>>>>> >>>>>>>>> Allowing Access >>>>>>>>> If you want setxkbmap to access this files, you need to relabel >>>>>>>>> them >>>>>>>>> using restorecon -v './.X11-unix'. You might want to relabel the >>>>>>>>> entire >>>>>>>>> directory using restorecon -R -v './.X11-unix'. >>>>>>>>> Additional Information >>>>>>>>> >>>>>>>>> Source Context: system_u:system_r:rhgb_t >>>>>>>>> Target Context: system_u:object_r:initrc_tmp_t >>>>>>>>> Target Objects: ./.X11-unix [ dir ] >>>>>>>>> Source: setxkbmap >>>>>>>>> Source Path: /usr/bin/setxkbmap >>>>>>>>> Port: >>>>>>>>> Host: C5.aardvark.com.au >>>>>>>>> Source RPM Packages: xorg-x11-xkb-utils-1.0.2-2.1 >>>>>>>>> Target RPM Packages: Policy RPM: >>>>>>>>> selinux-policy-2.4.6-225.el5 >>>>>>>>> Selinux Enabled: True >>>>>>>>> Policy Type: targeted >>>>>>>>> MLS Enabled: True >>>>>>>>> Enforcing Mode: Permissive >>>>>>>>> Plugin Name: home_tmp_bad_labels >>>>>>>>> Host Name: C5.aardvark.com.au >>>>>>>>> Platform: Linux C5.aardvark.com.au 2.6.18-128.4.1.el5 #1 >>>>>>>>> SMP Tue >>>>>>>>> Aug 4 20:19:25 EDT 2009 x86_64 x86_64 >>>>>>>>> Alert Count: 37 >>>>>>>>> First Seen: Sun Jan 11 17:55:13 2009 >>>>>>>>> Last Seen: Mon Aug 10 18:13:19 2009 >>>>>>>>> Local ID: 0950df01-cfad-420a-9e84-4996a8d31942 >>>>>>>>> Line Numbers: Raw Audit Messages : >>>>>>>>> >>>>>>>>> host=C5.aardvark.com.au type=AVC msg=audit(1249899199.903:20): >>>>>>>>> avc: >>>>>>>>> denied { search } for pid=4022 comm="setxkbmap" name=".X11-unix" >>>>>>>>> dev=dm-0 ino=27590701 scontext=system_u:system_r:rhgb_t:s0 >>>>>>>>> tcontext=system_u:object_r:initrc_tmp_t:s0 tclass=dir >>>>>>>>> host=C5.aardvark.com.au type=AVC msg=audit(1249899199.903:20): >>>>>>>>> avc: >>>>>>>>> denied { search } for pid=4022 comm="setxkbmap" name=".X11-unix" >>>>>>>>> dev=dm-0 ino=27590701 scontext=system_u:system_r:rhgb_t:s0 >>>>>>>>> tcontext=system_u:object_r:initrc_tmp_t:s0 tclass=dir >>>>>>>>> host=C5.aardvark.com.au type=SYSCALL msg=audit(1249899199.903:20): >>>>>>>>> arch=c000003e syscall=42 success=no exit=-2 a0=3 a1=7fffd74235b0 >>>>>>>>> a2=13 >>>>>>>>> a3=8 items=0 ppid=1 pid=4022 auid=4294967295 uid=0 gid=0 euid=0 >>>>>>>>> suid=0 >>>>>>>>> fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 >>>>>>>>> comm="setxkbmap" >>>>>>>>> exe="/usr/bin/setxkbmap" subj=system_u:system_r:rhgb_t:s0 >>>>>>>>> key=(null) >>>>>>>>> host=C5.aardvark.com.au type=SYSCALL msg=audit(1249899199.903:20): >>>>>>>>> arch=c000003e syscall=42 success=no exit=-2 a0=3 a1=7fffd74235b0 >>>>>>>>> a2=13 >>>>>>>>> a3=8 items=0 ppid=1 pid=4022 auid=4294967295 uid=0 gid=0 euid=0 >>>>>>>>> suid=0 >>>>>>>>> fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 >>>>>>>>> comm="setxkbmap" >>>>>>>>> exe="/usr/bin/setxkbmap" subj=system_u:system_r:rhgb_t:s0 >>>>>>>>> key=(null) >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> fedora-selinux-list mailing list >>>>>>>>> fedora-selinux-list at redhat.com >>>>>>>>> https://www.redhat.com/mailman/listinfo/fedora-selinux-list >>>>>>>>> >>>>>>>> chcon -R -t xserver_tmp_t /tmp/.X11-unix >>>>>>>> >>>>>>>> I always use tmpfs for /tmp, so I never end up with garbage on a >>>>>>>> reboot. >>>>>>>> >>>>>>>> >>>>>>> Thanks Daniel - but this is the response... >>>>>>> >>>>>>> [root at C5 ~]# chcon -R -t xserver_tmp_t /tmp/.X11-unix >>>>>>> chcon: failed to change context of /tmp/.X11-unix to >>>>>>> system_u:object_r:xserver_t mp_t: >>>>>>> Invalid >>>>>>> argument >>>>>>> chcon: failed to change context of /tmp/.X11-unix/X0 to >>>>>>> system_u:object_r:xserve r_tmp_t: >>>>>>> Invalid >>>>>>> argument >>>>>>> chcon: failed to change context of /tmp/.X11-unix/X1005 to >>>>>>> user_u:object_r:xserv er_tmp_t: Invalid >>>>>>> argument >>>>>>> [root at C5 ~]# >>>>>>> >>>>>>> Being pretty green - I don't really understand the problem here. >>>>>>> Also - >>>>>>> if this chcon worked - would this be a permanent solution - or >>>>>>> does it >>>>>>> need to be executed in a boot script? >>>>>>> I like your idea of using tmpfs - but is it ever a problem that >>>>>>> tmpfs is >>>>>>> relatively small and finite? Also - please excuse my ignorance - >>>>>>> but how >>>>>>> do I make tmpfs the tmp folder? >>>>>>> >>>>>>> Richard. >>>>>>> >>>>>>> >>>>>>> >>>>>> Must have changed between RHEL5 and F11 >>>>>> >>>>>> Try >>>>>> chcon -R -t xdm_xserver_tmp_t /tmp/.X11-unix >>>>>> >>>>>> Add this line to /etc/fstab >>>>>> >>>>>> tmpfs /tmp tmpfs >>>>>> rootcontext="system_u:object_r:tmp_t:s0",defaults 0 0 >>>>>> >>>>>> And reboot. >>>>>> >>>>>> I don't tend to store huge abouts of stuff in /tmp. If I want to >>>>>> store big stuff I can always use /var/tmp >>>>>> >>>>>> >>>>> Thanks Daniel >>>>> >>>>> That chcon command worked fine. Should this be a permanent solution >>>>> - or >>>>> will new files appearing there need a chcon too? Should I put this >>>>> command into a boot script somewhere? >>>>> >>>>> I'll try tmpfs and see if it ever overflows in practice. Hopefully >>>>> I'll >>>>> be able to see something in my logwatch if there is ever a problem. >>>>> Currently - It's using less than 1/2 its 2 gigs or ram - so there is >>>>> some room to spare. Seems your suggestion has sparked quite a bit of >>>>> interest...:-) >>>>> >>>>> Thanks again >>>>> >>>>> Richard. >>>>> >>>>> >>>>> >>>> No the chcon is fine. It was mislabeled at some point and relabeling >>>> does not touch /tmp >>>> >>>> >> >> I guess I would need to see the AVC messages, to make sure they are >> the same. >> >> What is the label on the /tmp/.X11-unix directory? >> >> > Hi Daniel > Does this answer your question? > > *> ls -Za /tmp* > drwxrwxrwt root root system_u:object_r:tmp_t . > drwxr-xr-x root root system_u:object_r:root_t .. > drwxrwxrwt root root system_u:object_r:xdm_tmp_t .ICE-unix > -r--r--r-- root root system_u:object_r:xdm_tmp_t .X0-lock > drwxrwxrwt root root system_u:object_r:initrc_tmp_t .X11-unix > drwxrwxrwt root root system_u:object_r:xfs_tmp_t .font-unix > srw-rw-rw- root root system_u:object_r:xdm_tmp_t .gdm_socket > -rw------- nx nx user_u:object_r:tmp_t .nX1000-lock > drwxr-xr-x root root root:object_r:initrc_tmp_t .webmin > drwx------ root root user_u:object_r:tmp_t gconfd-root > srwxr-xr-x root root user_u:object_r:tmp_t > gedit.root.3537314166 > srwxr-xr-x root root user_u:object_r:tmp_t mapping-root > -rw-r--r-- root root user_u:object_r:tmp_t sarg-file.in > > > > And just in case it is useful: > > *> ls -Za /tmp/.X11-unix* > drwxrwxrwt root root system_u:object_r:initrc_tmp_t . > drwxrwxrwt root root system_u:object_r:tmp_t .. > srwxrwxrwx root root system_u:object_r:initrc_tmp_t X0 > > > Here are the recent AVCs: > > Summary > SELinux is preventing the setxkbmap from using potentially mislabeled > files (./.X11-unix). > Detailed Description > [SELinux is in permissive mode, the operation would have been denied but > was permitted due to permissive mode.] > > SELinux has denied setxkbmap access to potentially mislabeled file(s) > (./.X11-unix). This means that SELinux will not allow setxkbmap to use > these files. It is common for users to edit files in their home > directory or tmp directories and then move (mv) them to system > directories. The problem is that the files end up with the wrong file > context which confined applications are not allowed to access. > > Allowing Access > If you want setxkbmap to access this files, you need to relabel them > using restorecon -v './.X11-unix'. You might want to relabel the entire > directory using restorecon -R -v './.X11-unix'. > Additional Information > > Source Context: system_u:system_r:rhgb_t > Target Context: system_u:object_r:initrc_tmp_t > Target Objects: ./.X11-unix [ dir ] > Source: setxkbmap > Source Path: /usr/bin/setxkbmap > Port: > Host: C5.aardvark.com.au > Source RPM Packages: xorg-x11-xkb-utils-1.0.2-2.1 > Target RPM Packages: > Policy RPM: selinux-policy-2.4.6-225.el5 > Selinux Enabled: True > Policy Type: targeted > MLS Enabled: True > Enforcing Mode: Permissive > Plugin Name: home_tmp_bad_labels > Host Name: C5.aardvark.com.au > Platform: Linux C5.aardvark.com.au 2.6.18-128.7.1.el5 #1 SMP Mon > Aug 24 08:21:56 EDT 2009 x86_64 x86_64 > Alert Count: 38 > First Seen: Sun Jan 11 17:55:13 2009 > Last Seen: Mon Aug 31 09:24:11 2009 > Local ID: 0950df01-cfad-420a-9e84-4996a8d31942 > Line Numbers: > > Raw Audit Messages : > > host=C5.aardvark.com.au type=AVC msg=audit(1251681851.968:15): avc: > denied { search } for pid=4135 comm="setxkbmap" name=".X11-unix" > dev=dm-0 ino=27590701 scontext=system_u:system_r:rhgb_t:s0 > tcontext=system_u:object_r:initrc_tmp_t:s0 tclass=dir > host=C5.aardvark.com.au type=AVC msg=audit(1251681851.968:15): avc: > denied { search } for pid=4135 comm="setxkbmap" name=".X11-unix" > dev=dm-0 ino=27590701 scontext=system_u:system_r:rhgb_t:s0 > tcontext=system_u:object_r:initrc_tmp_t:s0 tclass=dir > host=C5.aardvark.com.au type=SYSCALL msg=audit(1251681851.968:15): > arch=c000003e syscall=42 success=no exit=-2 a0=3 a1=7fff95f931b0 a2=13 > a3=0 items=0 ppid=1 pid=4135 auid=4294967295 uid=0 gid=0 euid=0 suid=0 > fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="setxkbmap" > exe="/usr/bin/setxkbmap" subj=system_u:system_r:rhgb_t:s0 key=(null) > host=C5.aardvark.com.au type=SYSCALL msg=audit(1251681851.968:15): > arch=c000003e syscall=42 success=no exit=-2 a0=3 a1=7fff95f931b0 a2=13 > a3=0 items=0 ppid=1 pid=4135 auid=4294967295 uid=0 gid=0 euid=0 suid=0 > fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="setxkbmap" > exe="/usr/bin/setxkbmap" subj=system_u:system_r:rhgb_t:s0 key=(null) > > > Summary > SELinux is preventing the setxkbmap from using potentially mislabeled > files (./.X11-unix). > Detailed Description > [SELinux is in permissive mode, the operation would have been denied but > was permitted due to permissive mode.] > > SELinux has denied setxkbmap access to potentially mislabeled file(s) > (./.X11-unix). This means that SELinux will not allow setxkbmap to use > these files. It is common for users to edit files in their home > directory or tmp directories and then move (mv) them to system > directories. The problem is that the files end up with the wrong file > context which confined applications are not allowed to access. > > Allowing Access > If you want setxkbmap to access this files, you need to relabel them > using restorecon -v './.X11-unix'. You might want to relabel the entire > directory using restorecon -R -v './.X11-unix'. > Additional Information > > Source Context: system_u:system_r:rhgb_t > Target Context: system_u:object_r:initrc_tmp_t > Target Objects: ./.X11-unix [ dir ] > Source: setxkbmap > Source Path: /usr/bin/setxkbmap > Port: > Host: C5.aardvark.com.au > Source RPM Packages: xorg-x11-xkb-utils-1.0.2-2.1 > Target RPM Packages: > Policy RPM: selinux-policy-2.4.6-225.el5 > Selinux Enabled: True > Policy Type: targeted > MLS Enabled: True > Enforcing Mode: Permissive > Plugin Name: home_tmp_bad_labels > Host Name: C5.aardvark.com.au > Platform: Linux C5.aardvark.com.au 2.6.18-128.7.1.el5 #1 SMP Mon > Aug 24 08:21:56 EDT 2009 x86_64 x86_64 > Alert Count: 39 > First Seen: Sun Jan 11 17:55:13 2009 > Last Seen: Mon Aug 31 09:24:13 2009 > Local ID: 0950df01-cfad-420a-9e84-4996a8d31942 > Line Numbers: > > Raw Audit Messages : > > host=C5.aardvark.com.au type=AVC msg=audit(1251681853.972:16): avc: > denied { search } for pid=4135 comm="setxkbmap" name=".X11-unix" > dev=dm-0 ino=27590701 scontext=system_u:system_r:rhgb_t:s0 > tcontext=system_u:object_r:initrc_tmp_t:s0 tclass=dir > host=C5.aardvark.com.au type=AVC msg=audit(1251681853.972:16): avc: > denied { search } for pid=4135 comm="setxkbmap" name=".X11-unix" > dev=dm-0 ino=27590701 scontext=system_u:system_r:rhgb_t:s0 > tcontext=system_u:object_r:initrc_tmp_t:s0 tclass=dir > host=C5.aardvark.com.au type=SYSCALL msg=audit(1251681853.972:16): > arch=c000003e syscall=42 success=no exit=-2 a0=3 a1=7fff95f931b0 a2=13 > a3=8 items=0 ppid=1 pid=4135 auid=4294967295 uid=0 gid=0 euid=0 suid=0 > fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="setxkbmap" > exe="/usr/bin/setxkbmap" subj=system_u:system_r:rhgb_t:s0 key=(null) > host=C5.aardvark.com.au type=SYSCALL msg=audit(1251681853.972:16): > arch=c000003e syscall=42 success=no exit=-2 a0=3 a1=7fff95f931b0 a2=13 > a3=8 items=0 ppid=1 pid=4135 auid=4294967295 uid=0 gid=0 euid=0 suid=0 > fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="setxkbmap" > exe="/usr/bin/setxkbmap" subj=system_u:system_r:rhgb_t:s0 key=(null) > The AVC messages that you attached do not show /tmp on a tmpfs file system, they look like they are still on an ext file system. Could you either switch to using /tmp on tmpfs or just execute mv /tmp/.X11-unix /tmp/.X11-unix.bad reboot And see what context the dirctory and its contents come up with. From ggw at wolves.durham.nc.us Tue Sep 1 21:56:50 2009 From: ggw at wolves.durham.nc.us (G.Wolfe Woodbury) Date: Tue, 01 Sep 2009 17:56:50 -0400 Subject: httpd and ~user/public_html Message-ID: <4A9D98A2.1080103@wolves.durham.nc.us> It seems to me that there should be a boolean to allow httpd to serve files from ~user/public_html without complaint. This lack forces me to run in permissive mode. -- G.Wolfe Woodbury From tibbs at math.uh.edu Tue Sep 1 22:50:01 2009 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Tue, 01 Sep 2009 17:50:01 -0500 Subject: httpd and ~user/public_html In-Reply-To: <4A9D98A2.1080103@wolves.durham.nc.us> (G. Wolfe Woodbury's message of "Tue, 01 Sep 2009 17:56:50 -0400") References: <4A9D98A2.1080103@wolves.durham.nc.us> Message-ID: >>>>> "GWW" == G Wolfe Woodbury writes: GWW> It seems to me that there should be a boolean to allow httpd to GWW> serve files from ~user/public_html without complaint. man httpd_selinux says: SELinux policy for httpd can be setup to not allowed to access users home directories. If you want to allow access to users home directories you need to set the httpd_enable_homedirs boolean and change the context of the files that you want people to access off the home dir. setsebool -P httpd_enable_homedirs 1 chcon -R -t httpd_sys_content_t ~user/public_html - J< From zheyeung at gmail.com Wed Sep 2 03:07:12 2009 From: zheyeung at gmail.com (zheyeung) Date: Wed, 2 Sep 2009 11:07:12 +0800 Subject: I cannot change my shell context Message-ID: <200909021107080933047@gmail.com> hi , every body ,I install selinux-policy-targeted in my F11,and run in enforce mode. now I want to change selinux context of /tmp/test,but failed.I thought current shell domain was unconfined_t. then I intend to change my shell context to root:sysadm_r: sysadm_t ,but also failed. my project team plan to develop selinux policy for our system based on selinux-policy.src.rpm. I guess is this package have not been developed? If it has been developed ,why I cannot change to sysadm_r: sysadm_t? ---------------------------------------------------------------------------- [root at localhost ~]# ls -lZ /tmp/testselinux root root unconfined_u:object_r:user_t:user_tmp_t: s0 /tmp/testselinux [root at localhost ~]#chcon unconfined_u:object_r:mytest_t /tmp/testselinux chcon:failed to change context of '/tmp/testselinux' to 'unconfined_u:object_r:testselinux: s0 : permission denied ## here mytest_t defined in myapp.pp,which has successfully loaded by "semodule -i myapp.pp" [root at localhost ~]# newrole -r sysadm_r -t sysadm_t unconfined_u:unconfined_r:unconfined_t: s0 is not valid context [root at localhost ~]# semanage login -m -s root -r s0-s0:c0.c1023 root after reboot, graphic terminal cannot run. audit says that system_u:system_r: xdm_t require "read" permission for system_u:object_r:httpd_sys_content_t. [root at localhost ~]# id context= root:unconfined_r:unconfined_t: s0-s0:c0-c1023 [root at localhost ~]# newrole -r sysadm_r -t sysadm_t failed to exec shell: permission denied 2009-09-02 zheyeung -------------- next part -------------- An HTML attachment was scrubbed... URL: From domg472 at gmail.com Wed Sep 2 08:30:56 2009 From: domg472 at gmail.com (Dominick Grift) Date: Wed, 2 Sep 2009 10:30:56 +0200 Subject: I cannot change my shell context In-Reply-To: <200909021107080933047@gmail.com> References: <200909021107080933047@gmail.com> Message-ID: <20090902083053.GA8272@notebook3.grift.internal> On Wed, Sep 02, 2009 at 11:07:12AM +0800, zheyeung wrote: > hi , every body ,I install selinux-policy-targeted in my F11,and run in enforce mode. > now I want to change selinux context of /tmp/test,but failed.I thought current shell domain was unconfined_t. then I intend to change my shell context to root:sysadm_r: sysadm_t ,but also failed. > my project team plan to develop selinux policy for our system based on selinux-policy.src.rpm. I guess is this package have not been developed? If it has been developed ,why I cannot change to sysadm_r: sysadm_t? > > ---------------------------------------------------------------------------- > > [root at localhost ~]# ls -lZ /tmp/testselinux > root root unconfined_u:object_r:user_t:user_tmp_t: s0 /tmp/testselinux This does security context does not makes senseto me . > > [root at localhost ~]#chcon unconfined_u:object_r:mytest_t /tmp/testselinux > chcon:failed to change context of '/tmp/testselinux' to 'unconfined_u:object_r:testselinux: s0 : permission denied This also does not make sense. > > ## here mytest_t defined in myapp.pp,which has successfully loaded by "semodule -i myapp.pp" Can you show us the module? > [root at localhost ~]# newrole -r sysadm_r -t sysadm_t > unconfined_u:unconfined_r:unconfined_t: s0 is not valid context > > [root at localhost ~]# semanage login -m -s root -r s0-s0:c0.c1023 root > > after reboot, graphic terminal cannot run. audit says that system_u:system_r: xdm_t require "read" permission for system_u:object_r:httpd_sys_content_t. I think this may be related to seuser roots default contexts in /etc/selinux/targeted/contexts/users/root. It seems theres is not default context defined for xdm_t there > [root at localhost ~]# id > context= root:unconfined_r:unconfined_t: s0-s0:c0-c1023 > > [root at localhost ~]# newrole -r sysadm_r -t sysadm_t > failed to exec shell: permission denied > 2009-09-02 > With regard to mapping root to seuser root i am not sure what you are trying to achieve. i think the root seuser is for MLS usage. But in either way i think if you edit the defaults contexts you should be able to make it work As for the labeling issue: the only sensible explanation i can come up with now is that mytest_t may not be defined a files_type. > > > zheyeung > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From chloekcy2000 at yahoo.ca Fri Sep 4 11:00:51 2009 From: chloekcy2000 at yahoo.ca (chloe K) Date: Fri, 4 Sep 2009 04:00:51 -0700 (PDT) Subject: selinux issue Message-ID: <996848.40215.qm@web57409.mail.re1.yahoo.com> > Hi all > how I have to set the selinux to disable? > to make webserver work > and > mysql work too > if not setting to 0, apache error log > (13)Permission denied: access to /admin denied > and mysql error > 090903 19:43:19 InnoDB: Operating system error number 13 in a file > operation. > InnoDB: The error means mysqld does not have the access rights to > InnoDB: the directory. > InnoDB: File name ./ibdata1 > InnoDB: File operation call: 'open'. > InnoDB: Cannot continue operation. > Thank you > __________________________________________________________________ Yahoo! Canada Toolbar: Search from anywhere on the web, and bookmark your favourite sites. Download it now http://ca.toolbar.yahoo.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From domg472 at gmail.com Fri Sep 4 12:00:02 2009 From: domg472 at gmail.com (Dominick Grift) Date: Fri, 4 Sep 2009 14:00:02 +0200 Subject: selinux issue In-Reply-To: <996848.40215.qm@web57409.mail.re1.yahoo.com> References: <996848.40215.qm@web57409.mail.re1.yahoo.com> Message-ID: <20090904120000.GB2709@notebook3.grift.internal> On Fri, Sep 04, 2009 at 04:00:51AM -0700, chloe K wrote: > > Hi all > > how I have to set the selinux to disable? > > to make webserver work > > and > > mysql work too > > if not setting to 0, apache error log > > (13)Permission denied: access to /admin denied > > and mysql error > > 090903 19:43:19 InnoDB: Operating system error number 13 in a file > > operation. > > InnoDB: The error means mysqld does not have the access rights to > > InnoDB: the directory. > > InnoDB: File name ./ibdata1 > > InnoDB: File operation call: 'open'. > > InnoDB: Cannot continue operation. > > Thank you > > > > > I do not have a simple solution to your issue. However, i can point you to some documentation that will help you solve your SELinux problems and help you get familiar with the matter: 1. http://docs.fedoraproject.org/selinux-user-guide/f11/en-US/ 2. http://docs.fedoraproject.org/selinux-managing-confined-services-guide/en-US/F11/html/ Please read through those documents they will help you understand more about SELinux hth > __________________________________________________________________ > Yahoo! Canada Toolbar: Search from anywhere on the web, and bookmark your favourite sites. Download it now > http://ca.toolbar.yahoo.com. > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From stefan at seekline.net Sun Sep 6 14:31:24 2009 From: stefan at seekline.net (Stefan Schulze Frielinghaus) Date: Sun, 06 Sep 2009 16:31:24 +0200 Subject: selinux-policy-2.4.6-203.el5 and kernel_sendrecv_unlabeled_association Message-ID: <1252247484.20898.22.camel@vogon.seekline.net> Why is the following rule removed by the patch of the SRPM package selinux-policy-2.4.6-203.el5? # temporary hack until labeling on packets is supported allow $1 unlabeled_t:packet { send recv }; The actual file is kernel/kernel.if and line 2170. The comment above indicates that this is a temporary hack but I get some AVCs and need to manually allow this rule. Couldn't we accept the temporary hack until something more useful is out? Because I (and guess some others too) need this rule. cheers Stefan From cochranb at speakeasy.net Thu Sep 10 02:37:52 2009 From: cochranb at speakeasy.net (Robert L Cochran) Date: Wed, 09 Sep 2009 22:37:52 -0400 Subject: Wordpress: How To Allow httpd to write to /usr/share/wordpress/wp-content/uploads Message-ID: <4AA86680.4020604@speakeasy.net> I installed Wordpress 2.8.3 on Fedora 11 and attempted to upload a photo to the directory /usr/share/wordpress/wp-content/uploads/2009/09/, but failed even though my Wordpress "author" role permits file uploads. Wordpress uses php for scripting. I suspected that I had set file permissions incorrectly. Here are the permissions on /usr: drwxrwxr-x. 16 root apache 4096 2009-04-12 19:05 usr I ran `setsebool`: [root at deafeng3 /]# setsebool -P allow_httpd_anon_write=1 [root at deafeng3 /]# service httpd restart Stopping httpd: [ OK ] Starting httpd: [ OK ] I wrote a php script to see if it can move a single file just to /usr/. Here is the error message that appears in /var/log/httpd/error_log: [Wed Sep 09 22:25:30 2009] [error] [client 127.0.0.1] PHP Warning: move_uploaded_file(/usr/Cochran.jpg) [function.move-uploaded-file]: failed to open stream: Permission denied in /var/www/html/testuploads.php on line 35, referer: http://localhost/testuploads.php [Wed Sep 09 22:25:30 2009] [error] [client 127.0.0.1] PHP Warning: move_uploaded_file() [function.move-uploaded-file]: Unable to move '/tmp/phpJFMNbS' to '/usr/Cochran.jpg' in /var/www/html/testuploads.php on line 35, referer: http://localhost/testuploads.php But I still can't write to /usr. If I can't write to that, how can I continue down the file hierarchy to write to the true target directory of /usr/share/wordpress/wp-content/uploads/*? That is to say, the uploads directory and every subdirectory under it should be writable by httpd. Thanks Bob Cochran From cochranb at speakeasy.net Thu Sep 10 02:53:58 2009 From: cochranb at speakeasy.net (Robert L Cochran) Date: Wed, 09 Sep 2009 22:53:58 -0400 Subject: Wordpress: How To Allow httpd to write to /usr/share/wordpress/wp-content/uploads In-Reply-To: <4AA86680.4020604@speakeasy.net> References: <4AA86680.4020604@speakeasy.net> Message-ID: <4AA86A46.4040805@speakeasy.net> On 09/09/2009 10:37 PM, Robert L Cochran wrote: > I installed Wordpress 2.8.3 on Fedora 11 and attempted to upload a > photo to the directory > /usr/share/wordpress/wp-content/uploads/2009/09/, but failed even > though my Wordpress "author" role permits file uploads. Wordpress uses > php for scripting. I suspected that I had set file permissions > incorrectly. Here are the permissions on /usr: > > drwxrwxr-x. 16 root apache 4096 2009-04-12 19:05 usr > > I ran `setsebool`: > > [root at deafeng3 /]# setsebool -P allow_httpd_anon_write=1 > [root at deafeng3 /]# service httpd restart > Stopping httpd: [ OK ] > Starting httpd: [ OK ] > > > I wrote a php script to see if it can move a single file just to > /usr/. Here is the error message that appears in > /var/log/httpd/error_log: > > [Wed Sep 09 22:25:30 2009] [error] [client 127.0.0.1] PHP Warning: > move_uploaded_file(/usr/Cochran.jpg) [ href='function.move-uploaded-file'>function.move-uploaded-file]: > failed to open stream: Permission denied in > /var/www/html/testuploads.php on line 35, referer: > http://localhost/testuploads.php > [Wed Sep 09 22:25:30 2009] [error] [client 127.0.0.1] PHP Warning: > move_uploaded_file() [ href='function.move-uploaded-file'>function.move-uploaded-file]: > Unable to move '/tmp/phpJFMNbS' to '/usr/Cochran.jpg' in > /var/www/html/testuploads.php on line 35, referer: > http://localhost/testuploads.php > > > But I still can't write to /usr. If I can't write to that, how can I > continue down the file hierarchy to write to the true target directory > of /usr/share/wordpress/wp-content/uploads/*? That is to say, the > uploads directory and every subdirectory under it should be writable > by httpd. > > Thanks > > Bob Cochran > I should have added: I am the one who made /usr group-owned by apache and then set the group permissions to rwx. In fact I've done quite a lot of fooling with file permissions in /usr/share/wordpress/*. Bob From domg472 at gmail.com Thu Sep 10 08:06:37 2009 From: domg472 at gmail.com (Dominick Grift) Date: Thu, 10 Sep 2009 10:06:37 +0200 Subject: Wordpress: How To Allow httpd to write to /usr/share/wordpress/wp-content/uploads In-Reply-To: <4AA86A46.4040805@speakeasy.net> References: <4AA86680.4020604@speakeasy.net> <4AA86A46.4040805@speakeasy.net> Message-ID: <20090910080636.GA22091@notebook3.grift.internal> On Wed, Sep 09, 2009 at 10:53:58PM -0400, Robert L Cochran wrote: > > On 09/09/2009 10:37 PM, Robert L Cochran wrote: >> I installed Wordpress 2.8.3 on Fedora 11 and attempted to upload a >> photo to the directory >> /usr/share/wordpress/wp-content/uploads/2009/09/, but failed even >> though my Wordpress "author" role permits file uploads. Wordpress uses >> php for scripting. I suspected that I had set file permissions >> incorrectly. Here are the permissions on /usr: see if this works: chcon -R -t httpd_sys_content_rw_t /usr/share/wordpress/wp-content/uploads/ >> >> drwxrwxr-x. 16 root apache 4096 2009-04-12 19:05 usr >> >> I ran `setsebool`: >> >> [root at deafeng3 /]# setsebool -P allow_httpd_anon_write=1 >> [root at deafeng3 /]# service httpd restart >> Stopping httpd: [ OK ] >> Starting httpd: [ OK ] >> >> >> I wrote a php script to see if it can move a single file just to >> /usr/. Here is the error message that appears in >> /var/log/httpd/error_log: >> >> [Wed Sep 09 22:25:30 2009] [error] [client 127.0.0.1] PHP Warning: >> move_uploaded_file(/usr/Cochran.jpg) [> href='function.move-uploaded-file'>function.move-uploaded-file]: >> failed to open stream: Permission denied in >> /var/www/html/testuploads.php on line 35, referer: >> http://localhost/testuploads.php >> [Wed Sep 09 22:25:30 2009] [error] [client 127.0.0.1] PHP Warning: >> move_uploaded_file() [> href='function.move-uploaded-file'>function.move-uploaded-file]: >> Unable to move '/tmp/phpJFMNbS' to '/usr/Cochran.jpg' in >> /var/www/html/testuploads.php on line 35, referer: >> http://localhost/testuploads.php >> >> >> But I still can't write to /usr. If I can't write to that, how can I >> continue down the file hierarchy to write to the true target directory >> of /usr/share/wordpress/wp-content/uploads/*? That is to say, the >> uploads directory and every subdirectory under it should be writable >> by httpd. >> >> Thanks >> >> Bob Cochran >> > > I should have added: I am the one who made /usr group-owned by apache > and then set the group permissions to rwx. In fact I've done quite a lot > of fooling with file permissions in /usr/share/wordpress/*. > > Bob > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From dwalsh at redhat.com Thu Sep 10 16:03:36 2009 From: dwalsh at redhat.com (Daniel J Walsh) Date: Thu, 10 Sep 2009 12:03:36 -0400 Subject: Wordpress: How To Allow httpd to write to /usr/share/wordpress/wp-content/uploads In-Reply-To: <4AA86680.4020604@speakeasy.net> References: <4AA86680.4020604@speakeasy.net> Message-ID: <4AA92358.8050202@redhat.com> On 09/09/2009 10:37 PM, Robert L Cochran wrote: > I installed Wordpress 2.8.3 on Fedora 11 and attempted to upload a photo > to the directory /usr/share/wordpress/wp-content/uploads/2009/09/, but > failed even though my Wordpress "author" role permits file uploads. > Wordpress uses php for scripting. I suspected that I had set file > permissions incorrectly. Here are the permissions on /usr: > > drwxrwxr-x. 16 root apache 4096 2009-04-12 19:05 usr > > I ran `setsebool`: > > [root at deafeng3 /]# setsebool -P allow_httpd_anon_write=1 > [root at deafeng3 /]# service httpd restart > Stopping httpd: [ OK ] > Starting httpd: [ OK ] > > > I wrote a php script to see if it can move a single file just to /usr/. > Here is the error message that appears in /var/log/httpd/error_log: > > [Wed Sep 09 22:25:30 2009] [error] [client 127.0.0.1] PHP Warning: > move_uploaded_file(/usr/Cochran.jpg) [ href='function.move-uploaded-file'>function.move-uploaded-file]: > failed to open stream: Permission denied in > /var/www/html/testuploads.php on line 35, referer: > http://localhost/testuploads.php > [Wed Sep 09 22:25:30 2009] [error] [client 127.0.0.1] PHP Warning: > move_uploaded_file() [ href='function.move-uploaded-file'>function.move-uploaded-file]: > Unable to move '/tmp/phpJFMNbS' to '/usr/Cochran.jpg' in > /var/www/html/testuploads.php on line 35, referer: > http://localhost/testuploads.php > > > But I still can't write to /usr. If I can't write to that, how can I > continue down the file hierarchy to write to the true target directory > of /usr/share/wordpress/wp-content/uploads/*? That is to say, the > uploads directory and every subdirectory under it should be writable by > httpd. > > Thanks > > Bob Cochran > > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list > > Could you send me the /var/log/audit/audit.log compressed. I would like to run it through setroubleshoot in rawhide and see what it suggests. /usr/share/wordpress/wp-content/uploads should be set to httpd_sys_content_rw_t and everything will work. From kaigai at ak.jp.nec.com Fri Sep 11 04:42:35 2009 From: kaigai at ak.jp.nec.com (KaiGai Kohei) Date: Fri, 11 Sep 2009 13:42:35 +0900 Subject: unconfined domain equals permissive? Message-ID: <4AA9D53B.3090503@ak.jp.nec.com> Dan, I could find the following policy at the recent rawhide policy. (such as selinux-policy-3.6.31-2.fc12.src.rpm). -------------------- interface(`unconfined_domain',` gen_require(` attribute unconfined_services; ') # unconfined_domain_noaudit($1) permissive $1; tunable_policy(`allow_execheap',` auditallow $1 self:process execheap; ') ') -------------------- Is it a workaround fix? Or, do you have a plan to change the definition of unconfined domains at the F-12/rawhide? The permissive domains are also allowed to bypass MLS/MCS rules, not only TE rules, so it seems to me its impact is a bit unignorable, if it is not a workaround. Thanks, -- OSS Platform Development Division, NEC KaiGai Kohei From dwalsh at redhat.com Fri Sep 11 12:21:54 2009 From: dwalsh at redhat.com (Daniel J Walsh) Date: Fri, 11 Sep 2009 08:21:54 -0400 Subject: unconfined domain equals permissive? In-Reply-To: <4AA9D53B.3090503@ak.jp.nec.com> References: <4AA9D53B.3090503@ak.jp.nec.com> Message-ID: <4AAA40E2.2070804@redhat.com> On 09/11/2009 12:42 AM, KaiGai Kohei wrote: > Dan, > > I could find the following policy at the recent rawhide policy. > (such as selinux-policy-3.6.31-2.fc12.src.rpm). > > -------------------- > interface(`unconfined_domain',` > gen_require(` > attribute unconfined_services; > ') > > # unconfined_domain_noaudit($1) > permissive $1; > > tunable_policy(`allow_execheap',` > auditallow $1 self:process execheap; > ') > ') > -------------------- > > Is it a workaround fix? Or, do you have a plan to change the definition > of unconfined domains at the F-12/rawhide? > > The permissive domains are also allowed to bypass MLS/MCS rules, not only > TE rules, so it seems to me its impact is a bit unignorable, if it is not > a workaround. > > Thanks, No this is temporary to help me find bugs in policy. I am encouraging people to remove the unconfined.pp policy package which takes away the unconfined_domain. So I am just gathering avc's until we release Beta1. I will probably change it back in about a week. From jm at row44.com Fri Sep 11 15:09:18 2009 From: jm at row44.com (Jon Mineiko) Date: Fri, 11 Sep 2009 10:09:18 -0500 Subject: unconfined domain equals permissive? In-Reply-To: <4AAA40E2.2070804@redhat.com> References: <4AA9D53B.3090503@ak.jp.nec.com> <4AAA40E2.2070804@redhat.com> Message-ID: <5EAF1230-4530-4308-82FE-E5C642777E79@row44.com> Can someone call me at 630-519-3323. I'm having a issue with syslog-ng permissions too. There doesn't seem to be a policy for me to enable in selinux. So I need help creating one. I found some documentation online that suggests there should be. On Sep 11, 2009, at 7:21 AM, Daniel J Walsh wrote: > On 09/11/2009 12:42 AM, KaiGai Kohei wrote: >> Dan, >> >> I could find the following policy at the recent rawhide policy. >> (such as selinux-policy-3.6.31-2.fc12.src.rpm). >> >> -------------------- >> interface(`unconfined_domain',` >> gen_require(` >> attribute unconfined_services; >> ') >> >> # unconfined_domain_noaudit($1) >> permissive $1; >> >> tunable_policy(`allow_execheap',` >> auditallow $1 self:process execheap; >> ') >> ') >> -------------------- >> >> Is it a workaround fix? Or, do you have a plan to change the >> definition >> of unconfined domains at the F-12/rawhide? >> >> The permissive domains are also allowed to bypass MLS/MCS rules, >> not only >> TE rules, so it seems to me its impact is a bit unignorable, if it >> is not >> a workaround. >> >> Thanks, > No this is temporary to help me find bugs in policy. I am > encouraging people to remove the unconfined.pp policy package which > takes away the unconfined_domain. So I am just gathering avc's > until we release Beta1. I will probably change it back in about a > week. > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list > Jon Mineiko Row44 Inc. jm at row44.com desk 630-519-3323 cell 708-321-0211 gtalk jm7000 at gmail.com ------BEGIN PGP PUBLIC KEY BLOCK----- Version: 9.9.1.287 mQENBEpLh1kBCADYsBo2yI2wpyuX/cXObnjMIv8OL1ea21ObpOHe9x2/LL1EYp7K +mlFhV4HntZ5bBpu7zX/fk4eF5ZCYubmrJwHn7M61hqLeo7SYnqlNQfqiQcw3+Xp fLKVfxQxxMMoSE3Wv4NRw267F1c4wcO1M7NgraFgem4OJWZDjwA3r4FkR4n6u9ia VxgVjugNniavUPI7TV4m+48K3kiqax8VZfaOxL31HMB6vaFjNYfI6xwM3mvkT/MT G3btkE6PfUvVW1tW32REHk4JT5GnM4Tf2YEmnVTWVvwXbtORIb84+ozqw3MWwb0g 0mUwOSHWtK7Ao3OlpMMnam+Q15s+NAK205nDABEBAAG0HUpPTiBNSU5FSUtPIDxq bUBkYXRhdGVsZS5jb20+iQGHBBABAgBxBQJKS43OMBSAAAAAACAAB3ByZWZlcnJl ZC1lbWFpbC1lbmNvZGluZ0BwZ3AuY29tcGdwbWltZQcLCQgHAwIKAhkBGRhsZGFw Oi8va2V5c2VydmVyLnBncC5jb20FGwMAAAADFgIBBR4BAAAABBUICQoACgkQ/AVQ TqDllmu+fwgAsN2QYlyKkhtPlHuhvTA7+Zso5oWms0/ipij0wfj0oLrrifz2Ku6u vauSat8H8BX1mVDRA7uT2cI/7umaQ8QGJWouTWokwAOgDGNdyLRpDI6ssI0i8MU9 Hv2+zKABtR7cdVsmgS3juTuyvAqxPrJ38AZEOxwY00dwwzPFlXFG8ybQ8rVzP1bD jnk+ol6Di53v6vpJ44iJqt83LW0dYrhwQWtgbt/p+vT6XdK9S6z2HJy+Wuvdh88f tBtxJ5p19gzSFZ71h4bOybbe4dXqZI+0U2RoMO2zYjV1zDugvpLQXCxqvYUSYwkR m4JLG2YPnBTC7DYDR8Z8q4z55n/k2W8gCrQeSk9OIE1JTkVJS08gPGptNzAwMEBn bWFpbC5jb20+iQGEBBABAgBuBQJKS43OMBSAAAAAACAAB3ByZWZlcnJlZC1lbWFp bC1lbmNvZGluZ0BwZ3AuY29tcGdwbWltZQcLCQgHAwIKGRhsZGFwOi8va2V5c2Vy dmVyLnBncC5jb20FGwMAAAADFgIBBR4BAAAABBUICQoACgkQ/AVQTqDllmsfZwgA jpbpL5oI6TP7KC/ZmhwjWX+l6mtFVsD35l6tR/0K/Dpo1Xc2wbsPzuwkl0/3EdB8 m40L5nOt4qSWXE4nCT+18jhmvaV8fDSm6k13/iz3M7gnLySzEyF9VMpxhpIxiHzJ gUhoOdj+RMsQQr3xxaobRN2PU9HeLJH+osFbQC3WrX0f+ha8speebe1zpNgoAzTZ rmOpHmOlBXeaNq0WrTr1F0UOIx45tvoYe1TYXvZMgw2hTimiaVoeY4dvqma0dxFS 7NJNl0F+q8b0cIKtdSyFwzh2I0fJFatyNqZSjeUKaq9uz2WCIpYn0jTseFVsF3E8 1Rp9GTb0kddKJyvY8XSHELQaSk9OIE1JTkVJS08gPGptQHJvdzQ0LmNvbT6JAYQE EAECAG4FAkpLjc4wFIAAAAAAIAAHcHJlZmVycmVkLWVtYWlsLWVuY29kaW5nQHBn cC5jb21wZ3BtaW1lBwsJCAcDAgoZGGxkYXA6Ly9rZXlzZXJ2ZXIucGdwLmNvbQUb AwAAAAMWAgEFHgEAAAAEFQgJCgAKCRD8BVBOoOWWa0yyCACmfj2KcTB+YMEoiNhT Xp4iXBVtxzppxmpercI3NFfx4rS+33Iy/4BPEYcdQqrr1xgVCXzv/BRmwwb41PPZ 6+tstMrS8APnqsW0RIxH3gYvXMu2k9oF9aNqc04vA7wJ4hnGtONyGDl2H3vGEm+Q qhPY6cCaPk2085hQq6pNou9XWDfun0tYhh0BhFxLpbgLAWm9EdSH0WxjfevAKIDs dixZutxscEnABmOoNkxBgOmCcewOKTvGhFdj+bVV/VelUSfyZryKiP44hzTntRKI jEmHA6aCDMPxicoQZFsz+KqgjYWslSwOdtd0uPe4g8gfkVoFGA17NWuWVONIVrFK H5ystCBKT04gTUlORUlLTyA8am1pbmVpa29Acm93NDQuY29tPokBhAQQAQIAbgUC SkuNzjAUgAAAAAAgAAdwcmVmZXJyZWQtZW1haWwtZW5jb2RpbmdAcGdwLmNvbXBn cG1pbWUHCwkIBwMCChkYbGRhcDovL2tleXNlcnZlci5wZ3AuY29tBRsDAAAAAxYC AQUeAQAAAAQVCAkKAAoJEPwFUE6g5ZZrmpEIAItF2XKLitkRdySD+l4qMPiTiGLe jLovMZV5zLi5zTYAdzlyE9s3fVNEH6/sDbj5NQM6AI3YU4t0+7p90I4TWUDFJfRb W/Rak/vaYWsSJCbeqSn1Q5hht0ffIXmzvmS1VXraTQ2Z3mSol8j/e51DkUtcVdae CxRpT0it5pOCkz6i4y96NM8ubD7wambmBCjr3lsX5vsev8LMDfgfBJFVs8KIUEyU SuPbKb4YT3ZV2uhbVCyLr1UJsvRTGa5fFJ6RZW2MzFmnAme+wyVPwFrqZu41OR7t QdmigZ3im24J61Ut35ak7FEhSN/1nCbHJisB7gb5oPr/sXXmMcha57wWN065AQ0E SkuHWgEIAMrJn6/XdkOgQBq2Sxmmn56YTOvf6iXGK4DJEqL5SIPGi9Q/JnWkyxgp I2YwDaZkuvMctM1MpzMy9XnEEfIIMgbdCsA0OF7lzMgpU6DKVcZeaDnjiEve84Be GNysMxBsGfkmPF+QJKHjUkCsJtl2sawoLWFd4rTOYtdYtzDd1WXKSJNAdeWrlL1e z1GY7xAqCfHJpW85dqJfC+1gg6BDYOGwyYGo0EimPcBhBI2MRq0bDhmDlp4TqW2p 2BcgbogM+CsUR4vstirdkZdgFaOm04rI+BHERnEEzKyARlFixbQtUabwxFhO7zYx WqLwlydiAvanq1E4ekrBEIIUW0RYEtMAEQEAAYkCQQQYAQIBKwUCSkuHWwUbDAAA AMBdIAQZAQgABgUCSkuHWgAKCRCbWL+CsfdQBrQJB/40dKjEWAuoGap5UlHMmA2B HG8k+yC8qmmO9MGD/mCBegBJOkILyjA+7JijwenKPAHEL6nDa5OEk+/jDxAWdku3 yuRdz4MOnb8tS0qorBLju4tddr4KcP1GlLjZdBlaK78si5QQRrx8/9fsF3LhRRK1 XrJ6aALld0SQxVKXUWrz3/xxVAPk0YyvV/U+Mh7Zwjf3R9mLp9XtFMmuokvWKNAD VAaS5BRFtqRcQjN7tcrVwafRsqpQiP+pp1m8hKg4OoYQHKDKNUzSlVCpoh9Gy7Nx 9jXpwHl1P/niKGt5KChat5q0t8quQbnKJwj/XAi08PxafnZTN8hn+Rbd2Wc/R4E9 AAoJEPwFUE6g5ZZrueIH/R+U/XVhxaa0bQ+SMd8xrw78ejquzyak2dHfHqgSEv1T 5ormbkLVNNzlYhhhn7JwL7eEU5wKdBW2AFmm6sF5TvkydnFDRHWz8NTSXeY59ua1 7xlulHIAAwJN78Bt1z1l+SXX4x6Z6X6CbFC00/LXoHqSCUixyak6L6jkmb2P5hvl z8pupWmnOarliIBN1FId06JSMs8TiqaGRIlDs4EAuW4zIRZke0zJBGP/P1OIEJcT 77s0QPqDVpvEK+yX7NUr/kAc3TUNj88Oov5s/eP5EPmiINctin8ISn43i8x/mPRl GDDXUTsabwhPNYCNk3PsPvfs79Akl0Bs9yCslDayj5E= =PDPT -----END PGP PUBLIC KEY BLOCK----- -------------- next part -------------- An HTML attachment was scrubbed... URL: From anmajumd at cisco.com Fri Sep 11 20:34:41 2009 From: anmajumd at cisco.com (Anamitra Dutta Majumdar (anmajumd)) Date: Fri, 11 Sep 2009 13:34:41 -0700 Subject: Unconfining root user in strict policy mode In-Reply-To: <4AAA40E2.2070804@redhat.com> References: <4AA9D53B.3090503@ak.jp.nec.com> <4AAA40E2.2070804@redhat.com> Message-ID: <4EF101F7236DB443A8FABF8164BFBD0C086B7277@xmb-sjc-223.amer.cisco.com> We need a way to unconfine the root user with the strict policy being loaded in RHEL5.4. Currently with the strict policy the security context for root user is root:staff_r:staff_t. Is there a way to do so. Thanks Anamitra & Radha From cochranb at speakeasy.net Sat Sep 12 02:21:47 2009 From: cochranb at speakeasy.net (Robert L Cochran) Date: Fri, 11 Sep 2009 22:21:47 -0400 Subject: Wordpress: How To Allow httpd to write to /usr/share/wordpress/wp-content/uploads In-Reply-To: <20090910080636.GA22091@notebook3.grift.internal> References: <4AA86680.4020604@speakeasy.net> <4AA86A46.4040805@speakeasy.net> <20090910080636.GA22091@notebook3.grift.internal> Message-ID: <4AAB05BB.3080600@speakeasy.net> On 09/10/2009 04:06 AM, Dominick Grift wrote: > On Wed, Sep 09, 2009 at 10:53:58PM -0400, Robert L Cochran wrote: > >> On 09/09/2009 10:37 PM, Robert L Cochran wrote: >> >>> I installed Wordpress 2.8.3 on Fedora 11 and attempted to upload a >>> photo to the directory >>> /usr/share/wordpress/wp-content/uploads/2009/09/, but failed even >>> though my Wordpress "author" role permits file uploads. Wordpress uses >>> php for scripting. I suspected that I had set file permissions >>> incorrectly. Here are the permissions on /usr: >>> > see if this works: > > chcon -R -t httpd_sys_content_rw_t /usr/share/wordpress/wp-content/uploads/ > Dominick, it does, and I want to thank you for your help. You and Dan Walsh very kindly pointed out the solution to me. I can now upload images to the Fedora version of Wordpress. I've filed a bug on this: https://bugzilla.redhat.com/show_bug.cgi?id=522897 Thanks Bob Cochran From olivares14031 at yahoo.com Sat Sep 12 20:38:01 2009 From: olivares14031 at yahoo.com (Antonio Olivares) Date: Sat, 12 Sep 2009 13:38:01 -0700 (PDT) Subject: too many sealerts, most have been reported, and still see denials Message-ID: <651134.68745.qm@web52610.mail.re2.yahoo.com> Dear fellow selinux experts, I am running rawhide on three machines one recently installed via old xfce spin, the new ones (F12-Alpha isos, dvd and livecd's) don't work because of bugs :(, I see lots of selinux denials, some deal with wine, wineserver, ..., windows applications that I need to use at school with my students. I see firefox stack, and I see others that have been reported. At the beginning there were only two or three erros, but when I started running the windows based programs I got the messages. I am thinking that it is not becoming fun anymore when I have to report those errors/bugs and they are reported back with CLOSED Repeated bug or fixed in selinux-policy, and I still see them again even though I have updated the machine[after I saw there there were indeed updates, because of a confusion with rawhide reports, broken deps was first and I thougnt there were no updates :( ] I don't know but I am getting a little bit upset at this situation, I tried to get a repository suggested by another member of the selinux-list to see if it would help me, but it is for x86_64 and not x86. It failed to work and I disabled it. I am seeing why many folks are disabling selinux, is there any reason as to why there are many changes taking place that *it is not worth filing bugs reports* because they will be CLOSED (NOT A BUG) or already a (DUPLICATE BUG). I appreciate the help that many users on this list have provided through many situations, but this is not getting any easier and my feeling is that if the trend continues Fedora 12 will not play nice to many users because selinux gets in the way of their computing :(, Thanks for any suggestions, advice and/or consolating words. I hope that things come back to normal a bit and sorry for venting out my frustrations. I had been trouble free since a good while but now it is becoming a pain, just starting up and I see the selinux star at the bottom of the panel, and I click on it and *many times I could not file bug reports*, when I did *they were DUPLICATE, or CLOSED, or fixed in selinux-policy-?????* Only to apply updates and start again and I see the bugs again :(, and have like 50 sealerts many of them related :( Regards, Antonio From justinmattock at gmail.com Sat Sep 12 20:46:55 2009 From: justinmattock at gmail.com (Justin P. Mattock) Date: Sat, 12 Sep 2009 13:46:55 -0700 Subject: too many sealerts, most have been reported, and still see denials In-Reply-To: <651134.68745.qm@web52610.mail.re2.yahoo.com> References: <651134.68745.qm@web52610.mail.re2.yahoo.com> Message-ID: <4AAC08BF.7030308@gmail.com> Antonio Olivares wrote: > Dear fellow selinux experts, > > I am running rawhide on three machines one recently installed via old xfce spin, the new ones (F12-Alpha isos, dvd and livecd's) don't work because of bugs :(, I see lots of selinux denials, some deal with wine, wineserver, ..., windows applications that I need to use at school with my students. I see firefox stack, and I see others that have been reported. At the beginning there were only two or three erros, but when I started running the windows based programs I got the messages. I am thinking that it is not becoming fun anymore when I have to report those errors/bugs and they are reported back with CLOSED Repeated bug or fixed in selinux-policy, and I still see them again even though I have updated the machine[after I saw there there were indeed updates, because of a confusion with rawhide reports, broken deps was first and I thougnt there were no updates :( ] > > I don't know but I am getting a little bit upset at this situation, I tried to get a repository suggested by another member of the selinux-list to see if it would help me, but it is for x86_64 and not x86. It failed to work and I disabled it. I am seeing why many folks are disabling selinux, is there any reason as to why there are many changes taking place that *it is not worth filing bugs reports* because they will be CLOSED (NOT A BUG) or already a (DUPLICATE BUG). > > I appreciate the help that many users on this list have provided through many situations, but this is not getting any easier and my feeling is that if the trend continues Fedora 12 will not play nice to many users because selinux gets in the way of their computing :(, > > Thanks for any suggestions, advice and/or consolating words. > > I hope that things come back to normal a bit and sorry for venting out my frustrations. I had been trouble free since a good while but now it is becoming a pain, just starting up and I see the selinux star at the bottom of the panel, and I click on it and *many times I could not file bug reports*, when I did *they were DUPLICATE, or CLOSED, or fixed in selinux-policy-?????* Only to apply updates and start again and I see the bugs again :(, and have like 50 sealerts many of them related :( > > Regards, > > Antonio > > > > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list > > Not exactly sure whats happening. keep in mind if your using a development versions of fedora, then you will run into issues.(if your on stable then you should be fine). As for the avc's being generated, tough to say As of now I'm running the latest policy, with a custom built system(LFS). One thing for sure, is if I move to a newer system there will be issues with gnome and the latest refpolicy due to the heavy development with refpolicy, and gnome. Have you tried using a different policy other than what fedora has? Justin P. Mattock From olivares14031 at yahoo.com Sat Sep 12 20:55:01 2009 From: olivares14031 at yahoo.com (Antonio Olivares) Date: Sat, 12 Sep 2009 13:55:01 -0700 (PDT) Subject: too many sealerts, most have been reported, and still see denials In-Reply-To: <4AAC08BF.7030308@gmail.com> Message-ID: <274139.88287.qm@web52607.mail.re2.yahoo.com> > Not exactly sure whats happening. keep in mind > if your using a development versions of fedora, > then you will run into issues.(if your on stable then > you should be fine). > I knew that ahead of time, but it did not seem to be this troublesome this time with Fedora 12. I have been testing since Fedora 5 Test 2 release and have not encountered as many denials as I have in this Fedora 12 testing phase. Guess many don't complain because they run selinux disabled selinux=0, or enforcing=0 so they don't care to report the issues? > > As for the avc's being generated, tough to say > As of now I'm running the latest policy, with a custom > built system(LFS). > One thing for sure, is if? I move to a newer system > there will be issues with gnome and the latest refpolicy > due to the heavy development with refpolicy, and gnome. > > Have you tried using a different policy other than what > fedora has? I don't know much about this :(, I am just using default Fedora policies. I guess I just need to be patient and let things work out one by one. When I get more pops and alerts, I should post here and to bugzilla and hope that the illness' are cured :) Regards, Antonio From justinmattock at gmail.com Sat Sep 12 21:12:42 2009 From: justinmattock at gmail.com (Justin P. Mattock) Date: Sat, 12 Sep 2009 14:12:42 -0700 Subject: too many sealerts, most have been reported, and still see denials In-Reply-To: <274139.88287.qm@web52607.mail.re2.yahoo.com> References: <274139.88287.qm@web52607.mail.re2.yahoo.com> Message-ID: <4AAC0ECA.9060703@gmail.com> Antonio Olivares wrote: >> Not exactly sure whats happening. keep in mind >> if your using a development versions of fedora, >> then you will run into issues.(if your on stable then >> you should be fine). >> >> > I knew that ahead of time, but it did not seem to be this troublesome this time with Fedora 12. I have been testing since Fedora 5 Test 2 release and have not encountered as many denials as I have in this Fedora 12 testing phase. Guess many don't complain because they run selinux disabled selinux=0, or enforcing=0 so they don't care to report the issues? > > depends, some people dislike SELinux, and some use it without issues. I personally have taken a liking to using SELinux, although sometimes do get myself in a jam, with some wrong configuration that causes a bit of frustration. As for the latest fedora(haven't tried 12) thought the system was very well built. >> As for the avc's being generated, tough to say >> As of now I'm running the latest policy, with a custom >> built system(LFS). >> One thing for sure, is if I move to a newer system >> there will be issues with gnome and the latest refpolicy >> due to the heavy development with refpolicy, and gnome. >> >> Have you tried using a different policy other than what >> fedora has? >> > > I don't know much about this :(, I am just using default Fedora policies. I guess I just need to be patient and let things work out one by one. When I get more pops and alerts, I should post here and to bugzilla and hope that the illness' are cured :) > > Regards, > > Antonio > > > > > That's fine. Sometimes these avc's might be being generated by a mislabel somewhere. If you can try and locate the location of what is being fired off(the avc denial should show you) then use: restorecon -R /tosomedir and see if this fixes your issue. if not try the #selinux irc list to see if somebody can help or the SELinux mailing lists(but keep in mind it is the weekend and those guys are normally off of work). And also don't worry, Ill try and help you out as much as I can.(doing a git bisect so I have plenty of time). Justin P. Mattock From fvillarreal at silice.biz Sat Sep 12 21:39:09 2009 From: fvillarreal at silice.biz (Fernando Villarreal) Date: Sat, 12 Sep 2009 18:39:09 -0300 Subject: Prevent selinux deactivation Message-ID: <9C4FE6FB-D7BD-4D2A-B950-83FA22CFC525@silice.biz> Hi all, I'm new with selinux and I'm looking for the way to protect some files and procceses from the root user. Of course I should prevent tha the root modify o deactivate selinux to access what i'm protecting. Is that possible? Thanks. Fernando. -------------- next part -------------- An HTML attachment was scrubbed... URL: From domg472 at gmail.com Sat Sep 12 22:11:04 2009 From: domg472 at gmail.com (Dominick Grift) Date: Sun, 13 Sep 2009 00:11:04 +0200 Subject: Prevent selinux deactivation In-Reply-To: <9C4FE6FB-D7BD-4D2A-B950-83FA22CFC525@silice.biz> References: <9C4FE6FB-D7BD-4D2A-B950-83FA22CFC525@silice.biz> Message-ID: <20090912221103.GA3474@notebook3.grift.internal> On Sat, Sep 12, 2009 at 06:39:09PM -0300, Fernando Villarreal wrote: > Hi all, > > I'm new with selinux and I'm looking for the way to protect some files > and procceses from the root user. > > Of course I should prevent tha the root modify o deactivate selinux to > access what i'm protecting. > > Is that possible? Yes, root can be restricted, but implementing it requires some experience with SELinux. I would suggest that one first gets familair with the basics of SELinux and the properties of SELinux policy. Here is a URL to a SELinux user guide: http://docs.fedoraproject.org/selinux-user-guide/f11/en-US/ Once you are confident with the basics of SELinux it will be easier to go on to the advanced configuration, and the community will be able to help you better with achieving your security goals. > > Thanks. > > Fernando. > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From eparis at redhat.com Sat Sep 12 23:07:26 2009 From: eparis at redhat.com (Eric Paris) Date: Sat, 12 Sep 2009 19:07:26 -0400 Subject: too many sealerts, most have been reported, and still see denials In-Reply-To: <274139.88287.qm@web52607.mail.re2.yahoo.com> References: <274139.88287.qm@web52607.mail.re2.yahoo.com> Message-ID: <1252796846.13780.20.camel@dhcp231-106.rdu.redhat.com> On Sat, 2009-09-12 at 13:55 -0700, Antonio Olivares wrote: > > Not exactly sure whats happening. keep in mind > > if your using a development versions of fedora, > > then you will run into issues.(if your on stable then > > you should be fine). > > > I knew that ahead of time, but it did not seem to be this troublesome this time with Fedora 12. I have been testing since Fedora 5 Test 2 release and have not encountered as many denials as I have in this Fedora 12 testing phase. Guess many don't complain because they run selinux disabled selinux=0, or enforcing=0 so they don't care to report the issues? No, the vast majority of the 'denials' aren't actually denials. Dan removed all unconfined domains and replaced them with permissive domains. An unconfined domain allows everything and audits nothing. A permissive domain allows everything but audits every time there is no allow rule for a given request. This has helped to define the actual needs of many of the unconfined domains. And hopefully we can remove them entirely in the future. Please keep filing bugs. It's no surprise you are getting more messages, but it shouldn't be really different than in previous development for the number of problems it actually causes. -Eric From olivares14031 at yahoo.com Sun Sep 13 00:35:02 2009 From: olivares14031 at yahoo.com (Antonio Olivares) Date: Sat, 12 Sep 2009 17:35:02 -0700 (PDT) Subject: too many sealerts, most have been reported, and still see denials In-Reply-To: <1252796846.13780.20.camel@dhcp231-106.rdu.redhat.com> Message-ID: <297676.70820.qm@web52607.mail.re2.yahoo.com> --- On Sat, 9/12/09, Eric Paris wrote: > From: Eric Paris > Subject: Re: too many sealerts, most have been reported, and still see denials > To: "Antonio Olivares" > Cc: "Justin P. Mattock" , fedora-selinux-list at redhat.com > Date: Saturday, September 12, 2009, 4:07 PM > On Sat, 2009-09-12 at 13:55 -0700, > Antonio Olivares wrote: > > > Not exactly sure whats happening. keep in mind > > > if your using a development versions of fedora, > > > then you will run into issues.(if your on stable > then > > > you should be fine). > > > > > I knew that ahead of time, but it did not seem to be > this troublesome this time with Fedora 12.? I have been > testing since Fedora 5 Test 2 release and have not > encountered as many denials as I have in this Fedora 12 > testing phase.? Guess many don't complain because they > run selinux disabled selinux=0, or enforcing=0 so they don't > care to report the issues?? > > No, the vast majority of the 'denials' aren't actually > denials.? Dan > removed all unconfined domains and replaced them with > permissive > domains.? An unconfined domain allows everything and > audits nothing.? A > permissive domain allows everything but audits every time > there is no > allow rule for a given request. > > This has helped to define the actual needs of many of the > unconfined > domains.? And hopefully we can remove them entirely in > the future. > Please keep filing bugs. > Thanks for encouraging me to keep filing bugs. I will continue running it and report errors whenever I can. I hope that the bug reporter works, because it breaks once in a while :( > > It's no surprise you are getting more messages, but it > shouldn't be > really different than in previous development for the > number of problems > it actually causes. > > -Eric > > Regards, Antonio From olivares14031 at yahoo.com Sun Sep 13 16:03:14 2009 From: olivares14031 at yahoo.com (Antonio Olivares) Date: Sun, 13 Sep 2009 09:03:14 -0700 (PDT) Subject: too many sealerts, most have been reported, and still see denials In-Reply-To: <297676.70820.qm@web52607.mail.re2.yahoo.com> Message-ID: <194023.36057.qm@web52612.mail.re2.yahoo.com> > > No, the vast majority of the 'denials' aren't > actually > > denials. Dan > > removed all unconfined domains and replaced them with > > permissive > > domains. An unconfined domain allows everything and > > audits nothing. A > > permissive domain allows everything but audits every > time > > there is no > > allow rule for a given request. > > > > This has helped to define the actual needs of many of > the > > unconfined > > domains. And hopefully we can remove them entirely > in > > the future. > > Please keep filing bugs. > > Here's one for modprobe.d https://bugzilla.redhat.com/show_bug.cgi?id=523039 https://bugzilla.redhat.com/show_bug.cgi?id=523040 some from dmesg to support ones on top SELinux: initialized (dev sysfs, type sysfs), uses genfs_contexts type=1403 audit(1252857173.233:3): policy loaded auid=4294967295 ses=4294967295 load_policy used greatest stack depth: 5448 bytes left dracut: Switching root type=1305 audit(1252857175.267:6): audit_enabled=0 old=1 auid=4294967295 ses=4294967295 subj=system_u:system_r:readahead_t:s0 res=1 udev: starting version 145 type=1400 audit(1252857180.016:7): avc: denied { read } for pid=334 comm="modprobe" name="modprobe.d" dev=dm-0 ino=14985 scontext=system_u:system_r:insmod_t:s0-s0:c0.c1023 tcontext=system_u:object_r:modules_conf_t:s0 tclass=dir type=1400 audit(1252857180.017:8): avc: denied { open } for pid=334 comm="modprobe" name="modprobe.d" dev=dm-0 ino=14985 scontext=system_u:system_r:insmod_t:s0-s0:c0.c1023 tcontext=system_u:object_r:modules_conf_t:s0 tclass=dir end_request: I/O error, dev fd0, sector 0 sis900.c: v1.08.10 Apr. 2 2006 sis900 0000:00:04.0: PCI INT A -> GSI 19 (level, low) -> IRQ 19 0000:00:04.0: Realtek RTL8201 PHY transceiver found at address 1. 0000:00:04.0: Using transceiver found at address 1 as default eth0: SiS 900 PCI Fast Ethernet at 0xb000, IRQ 19, 00:16:ec:7d:be:bd parport_pc 00:09: reported by Plug and Play ACPI parport0: PC-style at 0x378 (0x778), irq 7 [PCSPP,TRISTATE] ppdev: user-space parallel port driver Intel ICH 0000:00:02.7: PCI INT C -> GSI 18 (level, low) -> IRQ 18 intel8x0_measure_ac97_clock: measured 50745 usecs (2442 samples) intel8x0: clocking to 48000 type=1400 audit(1252857184.249:9): avc: denied { read } for pid=587 comm="modprobe" name="modprobe.d" dev=dm-0 ino=14985 scontext=system_u:system_r:insmod_t:s0 tcontext=system_u:object_r:modules_conf_t:s0 tclass=dir type=1400 audit(1252857184.249:10): avc: denied { open } for pid=587 comm="modprobe" name="modprobe.d" dev=dm-0 ino=14985 scontext=system_u:system_r:insmod_t:s0 tcontext=system_u:object_r:modules_conf_t:s0 tclass=dir device-mapper: multipath: version 1.1.0 loaded EXT4-fs (dm-0): internal journal on dm-0:8 kjournald starting. Commit interval 5 seconds EXT3 FS on sda1, internal journal EXT3-fs: mounted filesystem with ordered data mode. SELinux: initialized (dev sda1, type ext3), uses xattr SELinux: initialized (dev tmpfs, type tmpfs), uses transition SIDs Adding 950264k swap on /dev/mapper/vg_n63552-lv_swap. Priority:-1 extents:1 across:950264k SELinux: initialized (dev binfmt_misc, type binfmt_misc), uses genfs_contexts microcode: CPU0 sig=0xf29, pf=0x4, revision=0x0 platform microcode: firmware: requesting intel-ucode/0f-02-09 type=1400 audit(1252857189.780:11): avc: denied { read } for pid=725 comm="modprobe" name="modprobe.d" dev=dm-0 ino=14985 scontext=system_u:system_r:insmod_t:s0-s0:c0.c1023 tcontext=system_u:object_r:modules_conf_t:s0 tclass=dir type=1400 audit(1252857189.780:12): avc: denied { open } for pid=725 comm="modprobe" name="modprobe.d" dev=dm-0 ino=14985 scontext=system_u:system_r:insmod_t:s0-s0:c0.c1023 tcontext=system_u:object_r:modules_conf_t:s0 tclass=dir microcode: CPU1 sig=0xf29, pf=0x4, revision=0x0 platform microcode: firmware: requesting intel-ucode/0f-02-09 Microcode Update Driver: v2.00 , Peter Oruba microcode: CPU0 updated to revision 0x2e, date = 2004-08-11 microcode: CPU1 updated to revision 0x2e, date = 2004-08-11 Microcode Update Driver: v2.00 removed. p4-clockmod: P4/Xeon(TM) CPU On-Demand Clock Modulation available type=1400 audit(1252857190.717:13): avc: denied { read } for pid=795 comm="modprobe" name="modprobe.d" dev=dm-0 ino=14985 scontext=system_u:system_r:insmod_t:s0 tcontext=system_u:object_r:modules_conf_t:s0 tclass=dir type=1400 audit(1252857190.717:14): avc: denied { open } for pid=795 comm="modprobe" name="modprobe.d" dev=dm-0 ino=14985 scontext=system_u:system_r:insmod_t:s0 tcontext=system_u:object_r:modules_conf_t:s0 tclass=dir NET: Registered protocol family 10 lo: Disabled Privacy Extensions ip6_tables: (C) 2000-2006 Netfilter Core Team RPC: Registered udp transport module. RPC: Registered tcp transport module. SELinux: initialized (dev rpc_pipefs, type rpc_pipefs), uses genfs_contexts eth0: Media Link On 100mbps full-duplex Installing knfsd (copyright (C) 1996 okir at monad.swb.de). SELinux: initialized (dev nfsd, type nfsd), uses genfs_contexts eth0: no IPv6 routers present CPU0 attaching NULL sched-domain. CPU1 attaching NULL sched-domain. CPU0 attaching sched-domain: domain 0: span 0-1 level SIBLING groups: 0 1 CPU1 attaching sched-domain: domain 0: span 0-1 level SIBLING groups: 1 0 canberra-gtk-pl used greatest stack depth: 5236 bytes left fuse init (API version 7.12) SELinux: initialized (dev fuse, type fuse), uses genfs_contexts [root at n6355-2 ~]# uname -r 2.6.31-2.fc12.i686 Another one filed,but cut + paste failed :( Regards, Antonio From olivares14031 at yahoo.com Sun Sep 13 16:53:49 2009 From: olivares14031 at yahoo.com (Antonio Olivares) Date: Sun, 13 Sep 2009 09:53:49 -0700 (PDT) Subject: firefox and selinux alert, here's one maybe filed two or three times :( Message-ID: <441155.50750.qm@web52610.mail.re2.yahoo.com> https://bugzilla.redhat.com/show_bug.cgi?id=522917 Summary: SELinux is preventing /usr/lib/firefox-3.5.3/firefox from changing a writable memory segment executable. Detailed Description: [firefox has a permissive type (unconfined_t). This access was not denied.] The firefox application attempted to change the access protection of memory (e.g., allocated using malloc). This is a potential security problem. Applications should not be doing this. Applications are sometimes coded incorrectly and request this permission. The SELinux Memory Protection Tests (http://people.redhat.com/drepper/selinux-mem.html) web page explains how to remove this requirement. If firefox does not work and you need it to work, you can configure SELinux temporarily to allow this access until the application is fixed. Please file a bug report against this package. Allowing Access: If you trust firefox to run correctly, you can change the context of the executable to execmem_exec_t. "chcon -t execmem_exec_t '/usr/lib/firefox-3.5.3/firefox'". You must also change the default file context files on the system in order to preserve them even on a full relabel. "semanage fcontext -a -t execmem_exec_t '/usr/lib/firefox-3.5.3/firefox'" Fix Command: chcon -t execmem_exec_t '/usr/lib/firefox-3.5.3/firefox' Additional Information: Source Context unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1 023 Target Context unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1 023 Target Objects None [ process ] Source firefox Source Path /usr/lib/firefox-3.5.3/firefox Port Host (removed) Source RPM Packages firefox-3.5.3-1.fc12 Target RPM Packages Policy RPM selinux-policy-3.6.31-3.fc12 Selinux Enabled True Policy Type targeted MLS Enabled True Enforcing Mode Enforcing Plugin Name allow_execmem Host Name (removed) Platform Linux localhost.localdomain 2.6.31-2.fc12.i686 #1 SMP Thu Sep 10 00:41:03 EDT 2009 i686 i686 Alert Count 1 First Seen Sun 13 Sep 2009 11:47:14 AM CDT Last Seen Sun 13 Sep 2009 11:47:14 AM CDT Local ID 1c10f973-7768-4807-9482-d77739f533a2 Line Numbers Raw Audit Messages node=localhost.localdomain type=AVC msg=audit(1252860434.198:37): avc: denied { execmem } for pid=1910 comm="firefox" scontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tclass=process node=localhost.localdomain type=SYSCALL msg=audit(1252860434.198:37): arch=40000003 syscall=192 success=yes exit=1601536 a0=0 a1=1000 a2=7 a3=22 items=0 ppid=1898 pid=1910 auid=500 uid=500 gid=500 euid=500 suid=500 fsuid=500 egid=500 sgid=500 fsgid=500 tty=(none) ses=1 comm="firefox" exe="/usr/lib/firefox-3.5.3/firefox" subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 key=(null) Regards, Antonio From domg472 at gmail.com Sun Sep 13 17:57:09 2009 From: domg472 at gmail.com (Dominick Grift) Date: Sun, 13 Sep 2009 19:57:09 +0200 Subject: firefox and selinux alert, here's one maybe filed two or three times :( In-Reply-To: <441155.50750.qm@web52610.mail.re2.yahoo.com> References: <441155.50750.qm@web52610.mail.re2.yahoo.com> Message-ID: <20090913175707.GA19612@notebook3.grift.internal> On Sun, Sep 13, 2009 at 09:53:49AM -0700, Antonio Olivares wrote: This is actually a bug in firefox i believe. However no access is actually denied. It was just reporting that normally it would have been denied. The solution that is suggested by setroubleshoot would have worked if it was needed (it isnt because the action was allowed in this case) So the issue is known (waiting for a fix from mozilla) In the meantime the access is allowed by SELinux but logged. if you want to get rid of the "warning" you could temporarily label chcon -t execmem_exec_t /usr/lib/firefox-3.5.3/firefox Just have to wait for a fix for this known issue`:wq > https://bugzilla.redhat.com/show_bug.cgi?id=522917 > > > Summary: > > SELinux is preventing /usr/lib/firefox-3.5.3/firefox from changing a writable > memory segment executable. > > Detailed Description: > > [firefox has a permissive type (unconfined_t). This access was not denied.] > > The firefox application attempted to change the access protection of memory > (e.g., allocated using malloc). This is a potential security problem. > Applications should not be doing this. Applications are sometimes coded > incorrectly and request this permission. The SELinux Memory Protection Tests > (http://people.redhat.com/drepper/selinux-mem.html) web page explains how to > remove this requirement. If firefox does not work and you need it to work, you > can configure SELinux temporarily to allow this access until the application is > fixed. Please file a bug report against this package. > > Allowing Access: > > If you trust firefox to run correctly, you can change the context of the > executable to execmem_exec_t. "chcon -t execmem_exec_t > '/usr/lib/firefox-3.5.3/firefox'". You must also change the default file context > files on the system in order to preserve them even on a full relabel. "semanage > fcontext -a -t execmem_exec_t '/usr/lib/firefox-3.5.3/firefox'" > > Fix Command: > > chcon -t execmem_exec_t '/usr/lib/firefox-3.5.3/firefox' > > Additional Information: > > Source Context unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1 > 023 > Target Context unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1 > 023 > Target Objects None [ process ] > Source firefox > Source Path /usr/lib/firefox-3.5.3/firefox > Port > Host (removed) > Source RPM Packages firefox-3.5.3-1.fc12 > Target RPM Packages > Policy RPM selinux-policy-3.6.31-3.fc12 > Selinux Enabled True > Policy Type targeted > MLS Enabled True > Enforcing Mode Enforcing > Plugin Name allow_execmem > Host Name (removed) > Platform Linux localhost.localdomain 2.6.31-2.fc12.i686 #1 > SMP Thu Sep 10 00:41:03 EDT 2009 i686 i686 > Alert Count 1 > First Seen Sun 13 Sep 2009 11:47:14 AM CDT > Last Seen Sun 13 Sep 2009 11:47:14 AM CDT > Local ID 1c10f973-7768-4807-9482-d77739f533a2 > Line Numbers > > Raw Audit Messages > > node=localhost.localdomain type=AVC msg=audit(1252860434.198:37): avc: denied { execmem } for pid=1910 comm="firefox" scontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tclass=process > > node=localhost.localdomain type=SYSCALL msg=audit(1252860434.198:37): arch=40000003 syscall=192 success=yes exit=1601536 a0=0 a1=1000 a2=7 a3=22 items=0 ppid=1898 pid=1910 auid=500 uid=500 gid=500 euid=500 suid=500 fsuid=500 egid=500 sgid=500 fsgid=500 tty=(none) ses=1 comm="firefox" exe="/usr/lib/firefox-3.5.3/firefox" subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 key=(null) > > > Regards, > > Antonio > > > > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From sds at tycho.nsa.gov Mon Sep 14 17:46:01 2009 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Mon, 14 Sep 2009 13:46:01 -0400 Subject: mount point labels In-Reply-To: <1178108359.3443.42.camel@moss-spartans.epoch.ncsc.mil> References: <1178029814.26421.57.camel@moss-spartans.epoch.ncsc.mil> <1178037769.26421.80.camel@moss-spartans.epoch.ncsc.mil> <1178051693.4809.10.camel@localhost.localdomain> <1178105384.3443.11.camel@moss-spartans.epoch.ncsc.mil> <1178108359.3443.42.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <1252950361.13634.1021.camel@moss-pluto.epoch.ncsc.mil> On Wed, 2007-05-02 at 08:19 -0400, Stephen Smalley wrote: > On Wed, 2007-05-02 at 07:29 -0400, Stephen Smalley wrote: > > On Tue, 2007-05-01 at 14:34 -0600, Forrest Taylor wrote: > > > On Tue, 2007-05-01 at 12:42 -0400, Stephen Smalley wrote: > > > > > By the way, can mount point labels be applied to automounted file > > > > > systems? If so, how would I do that? Would I put the label into the > > > > > automount file (auto.*) in the /etc directory? > > > > > > > > You can specify mount options in your automounter maps (like > > > > auto.master), so you should be able to specify a context= option there > > > > too. I haven't specifically tried it though. > > > > > > I cannot get this to work in RHEL5. It complains if I have it in > > > auto.master (syntax error), so I tried to place an entry in auto.misc > > > (for /misc). It will mount, but not with the context that I specified. > > > The logs mention that it is using genfs_contexts. > > > > > > Looking at the mounts, I see that the options for the autofs mount point > > > include: context="" > > > > > > So, the options are not getting passed to the mount command, or are > > > being overridden by automount. Any other ideas? > > > > File a bug against autofs? > > The man page for auto.master says that any remaining command line > arguments without leading dashes after the map name are taken as options > (-o) to mount. So it seems like a bug if it doesn't pass through the > context= option properly. Anyone know if this got fixed in RHEL? -- Stephen Smalley National Security Agency From dwalsh at redhat.com Mon Sep 14 19:54:38 2009 From: dwalsh at redhat.com (Daniel J Walsh) Date: Mon, 14 Sep 2009 15:54:38 -0400 Subject: too many sealerts, most have been reported, and still see denials In-Reply-To: <194023.36057.qm@web52612.mail.re2.yahoo.com> References: <194023.36057.qm@web52612.mail.re2.yahoo.com> Message-ID: <4AAE9F7E.5020003@redhat.com> On 09/13/2009 12:03 PM, Antonio Olivares wrote: >>> No, the vast majority of the 'denials' aren't >> actually >>> denials. Dan >>> removed all unconfined domains and replaced them with >>> permissive >>> domains. An unconfined domain allows everything and >>> audits nothing. A >>> permissive domain allows everything but audits every >> time >>> there is no >>> allow rule for a given request. >>> >>> This has helped to define the actual needs of many of >> the >>> unconfined >>> domains. And hopefully we can remove them entirely >> in >>> the future. >>> Please keep filing bugs. >>> > Here's one for modprobe.d > > https://bugzilla.redhat.com/show_bug.cgi?id=523039 > > https://bugzilla.redhat.com/show_bug.cgi?id=523040 > > some from dmesg to support ones on top > > SELinux: initialized (dev sysfs, type sysfs), uses genfs_contexts > type=1403 audit(1252857173.233:3): policy loaded auid=4294967295 ses=4294967295 > load_policy used greatest stack depth: 5448 bytes left > dracut: Switching root > type=1305 audit(1252857175.267:6): audit_enabled=0 old=1 auid=4294967295 ses=4294967295 subj=system_u:system_r:readahead_t:s0 res=1 > udev: starting version 145 > type=1400 audit(1252857180.016:7): avc: denied { read } for pid=334 comm="modprobe" name="modprobe.d" dev=dm-0 ino=14985 scontext=system_u:system_r:insmod_t:s0-s0:c0.c1023 tcontext=system_u:object_r:modules_conf_t:s0 tclass=dir > type=1400 audit(1252857180.017:8): avc: denied { open } for pid=334 comm="modprobe" name="modprobe.d" dev=dm-0 ino=14985 scontext=system_u:system_r:insmod_t:s0-s0:c0.c1023 tcontext=system_u:object_r:modules_conf_t:s0 tclass=dir > end_request: I/O error, dev fd0, sector 0 > sis900.c: v1.08.10 Apr. 2 2006 > sis900 0000:00:04.0: PCI INT A -> GSI 19 (level, low) -> IRQ 19 > 0000:00:04.0: Realtek RTL8201 PHY transceiver found at address 1. > 0000:00:04.0: Using transceiver found at address 1 as default > eth0: SiS 900 PCI Fast Ethernet at 0xb000, IRQ 19, 00:16:ec:7d:be:bd > parport_pc 00:09: reported by Plug and Play ACPI > parport0: PC-style at 0x378 (0x778), irq 7 [PCSPP,TRISTATE] > ppdev: user-space parallel port driver > Intel ICH 0000:00:02.7: PCI INT C -> GSI 18 (level, low) -> IRQ 18 > intel8x0_measure_ac97_clock: measured 50745 usecs (2442 samples) > intel8x0: clocking to 48000 > type=1400 audit(1252857184.249:9): avc: denied { read } for pid=587 comm="modprobe" name="modprobe.d" dev=dm-0 ino=14985 scontext=system_u:system_r:insmod_t:s0 tcontext=system_u:object_r:modules_conf_t:s0 tclass=dir > type=1400 audit(1252857184.249:10): avc: denied { open } for pid=587 comm="modprobe" name="modprobe.d" dev=dm-0 ino=14985 scontext=system_u:system_r:insmod_t:s0 tcontext=system_u:object_r:modules_conf_t:s0 tclass=dir > device-mapper: multipath: version 1.1.0 loaded > EXT4-fs (dm-0): internal journal on dm-0:8 > kjournald starting. Commit interval 5 seconds > EXT3 FS on sda1, internal journal > EXT3-fs: mounted filesystem with ordered data mode. > SELinux: initialized (dev sda1, type ext3), uses xattr > SELinux: initialized (dev tmpfs, type tmpfs), uses transition SIDs > Adding 950264k swap on /dev/mapper/vg_n63552-lv_swap. Priority:-1 extents:1 across:950264k > SELinux: initialized (dev binfmt_misc, type binfmt_misc), uses genfs_contexts > microcode: CPU0 sig=0xf29, pf=0x4, revision=0x0 > platform microcode: firmware: requesting intel-ucode/0f-02-09 > type=1400 audit(1252857189.780:11): avc: denied { read } for pid=725 comm="modprobe" name="modprobe.d" dev=dm-0 ino=14985 scontext=system_u:system_r:insmod_t:s0-s0:c0.c1023 tcontext=system_u:object_r:modules_conf_t:s0 tclass=dir > type=1400 audit(1252857189.780:12): avc: denied { open } for pid=725 comm="modprobe" name="modprobe.d" dev=dm-0 ino=14985 scontext=system_u:system_r:insmod_t:s0-s0:c0.c1023 tcontext=system_u:object_r:modules_conf_t:s0 tclass=dir > microcode: CPU1 sig=0xf29, pf=0x4, revision=0x0 > platform microcode: firmware: requesting intel-ucode/0f-02-09 > Microcode Update Driver: v2.00 , Peter Oruba > microcode: CPU0 updated to revision 0x2e, date = 2004-08-11 > microcode: CPU1 updated to revision 0x2e, date = 2004-08-11 > Microcode Update Driver: v2.00 removed. > p4-clockmod: P4/Xeon(TM) CPU On-Demand Clock Modulation available > type=1400 audit(1252857190.717:13): avc: denied { read } for pid=795 comm="modprobe" name="modprobe.d" dev=dm-0 ino=14985 scontext=system_u:system_r:insmod_t:s0 tcontext=system_u:object_r:modules_conf_t:s0 tclass=dir > type=1400 audit(1252857190.717:14): avc: denied { open } for pid=795 comm="modprobe" name="modprobe.d" dev=dm-0 ino=14985 scontext=system_u:system_r:insmod_t:s0 tcontext=system_u:object_r:modules_conf_t:s0 tclass=dir > NET: Registered protocol family 10 > lo: Disabled Privacy Extensions > ip6_tables: (C) 2000-2006 Netfilter Core Team > RPC: Registered udp transport module. > RPC: Registered tcp transport module. > SELinux: initialized (dev rpc_pipefs, type rpc_pipefs), uses genfs_contexts > eth0: Media Link On 100mbps full-duplex > Installing knfsd (copyright (C) 1996 okir at monad.swb.de). > SELinux: initialized (dev nfsd, type nfsd), uses genfs_contexts > eth0: no IPv6 routers present > CPU0 attaching NULL sched-domain. > CPU1 attaching NULL sched-domain. > CPU0 attaching sched-domain: > domain 0: span 0-1 level SIBLING > groups: 0 1 > CPU1 attaching sched-domain: > domain 0: span 0-1 level SIBLING > groups: 1 0 > canberra-gtk-pl used greatest stack depth: 5236 bytes left > fuse init (API version 7.12) > SELinux: initialized (dev fuse, type fuse), uses genfs_contexts > [root at n6355-2 ~]# uname -r > 2.6.31-2.fc12.i686 > > Another one filed,but cut + paste failed :( > > Regards, > > Antonio > > > > > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list > > Just imagine if you are on the recieving end of all these bugs. Wine is a huge culpret and is being turned back into unconfined_domain. abrt was also causing lots of these denials. Most of which are fixed in the latest policy builds. THe bugs I received this weekend including the modules_conf_t are legitimate. From roberto.sassu at polito.it Tue Sep 15 13:57:45 2009 From: roberto.sassu at polito.it (Roberto Sassu) Date: Tue, 15 Sep 2009 15:57:45 +0200 Subject: SELinux: creating a per-user confined domain Message-ID: <200909151557.45860.roberto.sassu@polito.it> Hello all i'm new to SELinux. I'm trying to create per-user domains in a system running Fedora 11 with the targeted policy enabled. The reason for that is that i need to create transitions to different domains when users start the same application. I followed these steps: - written my custom policy module(posted as attachment) in order to create new roles user1_r, user2_r with the default domains user1_t and user2_t; - added to the system new selinux users user1_u and user2_u; - added to the system the new linux users user1 and user2; - associated user1 with user1_u and user2 with user2_u; - labeled home directories respectively with types user1_home_t and user2_home_t - created the two files user1_u and user2_u in /etc/selinux/targeted/contexts/users; Then i tried to connect in local to the ssh server from root to the user1 but it rejected the connection with this log messages (but no AVC warnings): Sep 15 15:39:19 seclab05 sshd[5014]: Accepted password for user1 from ::1 port 53163 ssh2 Sep 15 15:39:19 seclab05 sshd[5014]: pam_selinux(sshd:session): conversation failed Sep 15 15:39:19 seclab05 sshd[5014]: pam_selinux(sshd:session): No response to query: Would you like to enter a security context? [N] Sep 15 15:39:19 seclab05 sshd[5014]: pam_selinux(sshd:session): Unable to get valid context for user1 Sep 15 15:39:19 seclab05 sshd[5014]: pam_unix(sshd:session): session opened for user user1 by (uid=0) Sep 15 15:39:19 seclab05 sshd[5014]: error: PAM: pam_open_session(): Authentication failure Sep 15 15:39:19 seclab05 sshd[5014]: error: ssh_selinux_setup_pty: security_compute_relabel: Invalid argument If putting the system in permissive mode the connection was successful but the security context after login was: system_u:system_r:unconfined_t:s0-s0:c0.c1023 Any suggestions? Thanks in advance. -------------- next part -------------- policy_module(usermod,1.0.0) userdom_base_user_template(user1) userdom_base_user_template(user2) access_to_home(user1) access_to_home(user2) -------------- next part -------------- ## interface(`access_to_home',` require { type home_root_t; type local_login_t, fs_t, proc_t, sshd_t; } type $1_home_t; type_transition $1_t $1_home_t:{file dir} $1_home_t; allow local_login_t $1_home_t:dir search; allow $1_t $1_home_t:dir { write search read create open getattr add_name }; allow $1_t $1_home_t:file { read write create open getattr append }; allow $1_t home_root_t:dir { search read open getattr }; allow $1_home_t fs_t:filesystem associate; allow $1_t proc_t:file { read open }; allow sshd_t $1_home_t:dir search; ') -------------- next part -------------- /home/user1(/.*)? gen_context(user1_u:object_r:user1_home_t,s0) /home/user2(/.*)? gen_context(user2_u:object_r:user2_home_t,s0) -------------- next part -------------- Labeling MLS/ MLS/ SELinux User Prefix MCS Level MCS Range SELinux Roles guest_u user s0 s0 guest_r root user s0 s0-s0:c0.c1023 staff_r sysadm_r system_r unconfined_r staff_u user s0 s0-s0:c0.c1023 staff_r sysadm_r system_r sysadm_u user s0 s0-s0:c0.c1023 sysadm_r system_u user s0 s0-s0:c0.c1023 system_r unconfined_u user s0 s0-s0:c0.c1023 system_r unconfined_r user1_u user1 s0 s0 user1_r user2_u user2 s0 s0 user2_r user4 user s0 s0 user_r user_u user s0 s0-s0:c0.c1023 user_r xguest_u user s0 s0 xguest_r -------------- next part -------------- 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 test1 user_u s0 user1 user1_u s0 user2 user2_u s0 user4 user_u s0 From domg472 at gmail.com Tue Sep 15 14:37:37 2009 From: domg472 at gmail.com (Dominick Grift) Date: Tue, 15 Sep 2009 16:37:37 +0200 Subject: SELinux: creating a per-user confined domain In-Reply-To: <200909151557.45860.roberto.sassu@polito.it> References: <200909151557.45860.roberto.sassu@polito.it> Message-ID: <20090915143735.GA2579@notebook3.grift.internal> On Tue, Sep 15, 2009 at 03:57:45PM +0200, Roberto Sassu wrote: > Hello all > > i'm new to SELinux. I'm trying to create per-user domains in a system running > Fedora 11 with the targeted policy enabled. The reason for that is that i need > to create transitions to different domains when users start the same > application. > I followed these steps: > - written my custom policy module(posted as attachment) in order to create new > roles user1_r, user2_r with the default domains user1_t and user2_t; > - added to the system new selinux users user1_u and user2_u; > - added to the system the new linux users user1 and user2; > - associated user1 with user1_u and user2 with user2_u; > - labeled home directories respectively with types user1_home_t and > user2_home_t > - created the two files user1_u and user2_u in > /etc/selinux/targeted/contexts/users; > > Then i tried to connect in local to the ssh server from root to the user1 but > it rejected the connection with this log messages (but no AVC warnings): > > Sep 15 15:39:19 seclab05 sshd[5014]: Accepted password for user1 from ::1 port > 53163 ssh2 > Sep 15 15:39:19 seclab05 sshd[5014]: pam_selinux(sshd:session): conversation > failed > Sep 15 15:39:19 seclab05 sshd[5014]: pam_selinux(sshd:session): No response to > query: Would you like to enter a security context? [N] > Sep 15 15:39:19 seclab05 sshd[5014]: pam_selinux(sshd:session): Unable to get > valid context for user1 > Sep 15 15:39:19 seclab05 sshd[5014]: pam_unix(sshd:session): session opened > for user user1 by (uid=0) > Sep 15 15:39:19 seclab05 sshd[5014]: error: PAM: pam_open_session(): > Authentication failure > Sep 15 15:39:19 seclab05 sshd[5014]: error: ssh_selinux_setup_pty: > security_compute_relabel: Invalid argument > > If putting the system in permissive mode the connection was successful but the > security context after login was: system_u:system_r:unconfined_t:s0-s0:c0.c1023 > Any suggestions? Thanks in advance. > > > policy_module(usermod,1.0.0) > > > userdom_base_user_template(user1) > userdom_base_user_template(user2) > > > access_to_home(user1) > access_to_home(user2) > > ## > > interface(`access_to_home',` > require { > type home_root_t; > type local_login_t, fs_t, proc_t, sshd_t; > } > > type $1_home_t; > > type_transition $1_t $1_home_t:{file dir} $1_home_t; > > allow local_login_t $1_home_t:dir search; > allow $1_t $1_home_t:dir { write search read create open getattr add_name }; > allow $1_t $1_home_t:file { read write create open getattr append }; > allow $1_t home_root_t:dir { search read open getattr }; > allow $1_home_t fs_t:filesystem associate; > allow $1_t proc_t:file { read open }; > allow sshd_t $1_home_t:dir search; > ') > > /home/user1(/.*)? gen_context(user1_u:object_r:user1_home_t,s0) > /home/user2(/.*)? gen_context(user2_u:object_r:user2_home_t,s0) > > Labeling MLS/ MLS/ > SELinux User Prefix MCS Level MCS Range SELinux Roles > > guest_u user s0 s0 guest_r > root user s0 s0-s0:c0.c1023 staff_r sysadm_r system_r unconfined_r > staff_u user s0 s0-s0:c0.c1023 staff_r sysadm_r system_r > sysadm_u user s0 s0-s0:c0.c1023 sysadm_r > system_u user s0 s0-s0:c0.c1023 system_r > unconfined_u user s0 s0-s0:c0.c1023 system_r unconfined_r > user1_u user1 s0 s0 user1_r > user2_u user2 s0 s0 user2_r > user4 user s0 s0 user_r > user_u user s0 s0-s0:c0.c1023 user_r > xguest_u user s0 s0 xguest_r > > 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 > test1 user_u s0 > user1 user1_u s0 > user2 user2_u s0 > user4 user_u s0 My first thought is that there may be errors in the /etc/selinux/targeted/contexts/users/user{1_u,2_u} files. My second thought is that it may have to do with your exotic home dir solution. I would not do that because it may require lots of policy and the results may not be so beneficial. > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From domg472 at gmail.com Tue Sep 15 15:25:11 2009 From: domg472 at gmail.com (Dominick Grift) Date: Tue, 15 Sep 2009 17:25:11 +0200 Subject: SELinux: creating a per-user confined domain In-Reply-To: <200909151557.45860.roberto.sassu@polito.it> References: <200909151557.45860.roberto.sassu@polito.it> Message-ID: <20090915152509.GB2579@notebook3.grift.internal> On Tue, Sep 15, 2009 at 03:57:45PM +0200, Roberto Sassu wrote: > Hello all > > i'm new to SELinux. I'm trying to create per-user domains in a system running > Fedora 11 with the targeted policy enabled. The reason for that is that i need > to create transitions to different domains when users start the same > application. > I followed these steps: > - written my custom policy module(posted as attachment) in order to create new > roles user1_r, user2_r with the default domains user1_t and user2_t; > - added to the system new selinux users user1_u and user2_u; > - added to the system the new linux users user1 and user2; > - associated user1 with user1_u and user2 with user2_u; > - labeled home directories respectively with types user1_home_t and > user2_home_t > - created the two files user1_u and user2_u in > /etc/selinux/targeted/contexts/users; > > Then i tried to connect in local to the ssh server from root to the user1 but > it rejected the connection with this log messages (but no AVC warnings): > > Sep 15 15:39:19 seclab05 sshd[5014]: Accepted password for user1 from ::1 port > 53163 ssh2 > Sep 15 15:39:19 seclab05 sshd[5014]: pam_selinux(sshd:session): conversation > failed > Sep 15 15:39:19 seclab05 sshd[5014]: pam_selinux(sshd:session): No response to > query: Would you like to enter a security context? [N] > Sep 15 15:39:19 seclab05 sshd[5014]: pam_selinux(sshd:session): Unable to get > valid context for user1 > Sep 15 15:39:19 seclab05 sshd[5014]: pam_unix(sshd:session): session opened > for user user1 by (uid=0) > Sep 15 15:39:19 seclab05 sshd[5014]: error: PAM: pam_open_session(): > Authentication failure > Sep 15 15:39:19 seclab05 sshd[5014]: error: ssh_selinux_setup_pty: > security_compute_relabel: Invalid argument > > If putting the system in permissive mode the connection was successful but the > security context after login was: system_u:system_r:unconfined_t:s0-s0:c0.c1023 > Any suggestions? Thanks in advance. > > > policy_module(usermod,1.0.0) > > > userdom_base_user_template(user1) > userdom_base_user_template(user2) > > > access_to_home(user1) > access_to_home(user2) > > ## > > interface(`access_to_home',` > require { > type home_root_t; > type local_login_t, fs_t, proc_t, sshd_t; > } > > type $1_home_t; > > type_transition $1_t $1_home_t:{file dir} $1_home_t; > > allow local_login_t $1_home_t:dir search; > allow $1_t $1_home_t:dir { write search read create open getattr add_name }; > allow $1_t $1_home_t:file { read write create open getattr append }; > allow $1_t home_root_t:dir { search read open getattr }; > allow $1_home_t fs_t:filesystem associate; > allow $1_t proc_t:file { read open }; > allow sshd_t $1_home_t:dir search; > ') > > /home/user1(/.*)? gen_context(user1_u:object_r:user1_home_t,s0) > /home/user2(/.*)? gen_context(user2_u:object_r:user2_home_t,s0) > > Labeling MLS/ MLS/ > SELinux User Prefix MCS Level MCS Range SELinux Roles > > guest_u user s0 s0 guest_r > root user s0 s0-s0:c0.c1023 staff_r sysadm_r system_r unconfined_r > staff_u user s0 s0-s0:c0.c1023 staff_r sysadm_r system_r > sysadm_u user s0 s0-s0:c0.c1023 sysadm_r > system_u user s0 s0-s0:c0.c1023 system_r > unconfined_u user s0 s0-s0:c0.c1023 system_r unconfined_r > user1_u user1 s0 s0 user1_r > user2_u user2 s0 s0 user2_r > user4 user s0 s0 user_r > user_u user s0 s0-s0:c0.c1023 user_r > xguest_u user s0 s0 xguest_r > > 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 > test1 user_u s0 > user1 user1_u s0 > user2 user2_u s0 > user4 user_u s0 oh, and the userdom template you are using does not have all the permissions for a login user i believe. i would just base if it on the current user_u policy so probably: userdom_unpriv_user_template() Also if you doo not see avc denials try: semodule -DB / -B to show/hide silenced denials Also keep an eye on messages for DBUS denials. > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From dwalsh at redhat.com Tue Sep 15 15:40:59 2009 From: dwalsh at redhat.com (Daniel J Walsh) Date: Tue, 15 Sep 2009 11:40:59 -0400 Subject: SELinux: creating a per-user confined domain In-Reply-To: <200909151557.45860.roberto.sassu@polito.it> References: <200909151557.45860.roberto.sassu@polito.it> Message-ID: <4AAFB58B.90002@redhat.com> On 09/15/2009 09:57 AM, Roberto Sassu wrote: > Hello all > > i'm new to SELinux. I'm trying to create per-user domains in a system running > Fedora 11 with the targeted policy enabled. The reason for that is that i need > to create transitions to different domains when users start the same > application. > I followed these steps: > - written my custom policy module(posted as attachment) in order to create new > roles user1_r, user2_r with the default domains user1_t and user2_t; > - added to the system new selinux users user1_u and user2_u; > - added to the system the new linux users user1 and user2; > - associated user1 with user1_u and user2 with user2_u; > - labeled home directories respectively with types user1_home_t and > user2_home_t > - created the two files user1_u and user2_u in > /etc/selinux/targeted/contexts/users; > > Then i tried to connect in local to the ssh server from root to the user1 but > it rejected the connection with this log messages (but no AVC warnings): > > Sep 15 15:39:19 seclab05 sshd[5014]: Accepted password for user1 from ::1 port > 53163 ssh2 > Sep 15 15:39:19 seclab05 sshd[5014]: pam_selinux(sshd:session): conversation > failed > Sep 15 15:39:19 seclab05 sshd[5014]: pam_selinux(sshd:session): No response to > query: Would you like to enter a security context? [N] > Sep 15 15:39:19 seclab05 sshd[5014]: pam_selinux(sshd:session): Unable to get > valid context for user1 > Sep 15 15:39:19 seclab05 sshd[5014]: pam_unix(sshd:session): session opened > for user user1 by (uid=0) > Sep 15 15:39:19 seclab05 sshd[5014]: error: PAM: pam_open_session(): > Authentication failure > Sep 15 15:39:19 seclab05 sshd[5014]: error: ssh_selinux_setup_pty: > security_compute_relabel: Invalid argument > > If putting the system in permissive mode the connection was successful but the > security context after login was: system_u:system_r:unconfined_t:s0-s0:c0.c1023 > Any suggestions? Thanks in advance. > > > > > ------------------------------------------------------------------------ > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list You probably need to create /etc/selinux/targeted/context/user1 and user2 Base these off of xguest I am not crazy about having home content variable between users, I think this is a waste of time. Others disagree. From myrobmail at gmail.com Tue Sep 15 18:30:43 2009 From: myrobmail at gmail.com (Roberto Sassu) Date: Tue, 15 Sep 2009 20:30:43 +0200 Subject: SELinux: creating a per-user confined domain In-Reply-To: <4AAFB58B.90002@redhat.com> References: <200909151557.45860.roberto.sassu@polito.it> <4AAFB58B.90002@redhat.com> Message-ID: Thanks all for replies. I have modified the policy by using the template userdom_unpriv_user_template() and everything is ok. Talking about different labels for each home directory i'm not sure but if all users domains have access to the default type user_home_dir_t access control on files under /home will be based on DAC mechanism. My effort is focused on trying to evaluate if it is possible with SELinux to protect files using as criteria for access decision the combination user identity-application-identity. For example i want to protect the user's private key allowing the access only to the program "ssh" ran by the user "user1". In my policy i created the domain "user1_t" which is set by the login program when "user1" logs in the system. Then i called the interface ssh_basic_client_template(user1, user1_t, user1_r) which creates the derived domain user1_ssh_t at the time user1 executes the "ssh" command. The file $home/.ssh/id_rsa could be labeled with a unique label and a specific rule can be added to allow only the user1_ssh_t domain to read the key. Denying to users the ability to set security contexts, does this policy create a separation between the ssh application and the others ran by the same user? On Tue, Sep 15, 2009 at 5:40 PM, Daniel J Walsh wrote: > On 09/15/2009 09:57 AM, Roberto Sassu wrote: > > Hello all > > > > i'm new to SELinux. I'm trying to create per-user domains in a system > running > > Fedora 11 with the targeted policy enabled. The reason for that is that i > need > > to create transitions to different domains when users start the same > > application. > > I followed these steps: > > - written my custom policy module(posted as attachment) in order to > create new > > roles user1_r, user2_r with the default domains user1_t and user2_t; > > - added to the system new selinux users user1_u and user2_u; > > - added to the system the new linux users user1 and user2; > > - associated user1 with user1_u and user2 with user2_u; > > - labeled home directories respectively with types user1_home_t and > > user2_home_t > > - created the two files user1_u and user2_u in > > /etc/selinux/targeted/contexts/users; > > > > Then i tried to connect in local to the ssh server from root to the user1 > but > > it rejected the connection with this log messages (but no AVC warnings): > > > > Sep 15 15:39:19 seclab05 sshd[5014]: Accepted password for user1 from ::1 > port > > 53163 ssh2 > > Sep 15 15:39:19 seclab05 sshd[5014]: pam_selinux(sshd:session): > conversation > > failed > > Sep 15 15:39:19 seclab05 sshd[5014]: pam_selinux(sshd:session): No > response to > > query: Would you like to enter a security context? [N] > > Sep 15 15:39:19 seclab05 sshd[5014]: pam_selinux(sshd:session): Unable to > get > > valid context for user1 > > Sep 15 15:39:19 seclab05 sshd[5014]: pam_unix(sshd:session): session > opened > > for user user1 by (uid=0) > > Sep 15 15:39:19 seclab05 sshd[5014]: error: PAM: pam_open_session(): > > Authentication failure > > Sep 15 15:39:19 seclab05 sshd[5014]: error: ssh_selinux_setup_pty: > > security_compute_relabel: Invalid argument > > > > If putting the system in permissive mode the connection was successful > but the > > security context after login was: > system_u:system_r:unconfined_t:s0-s0:c0.c1023 > > Any suggestions? Thanks in advance. > > > > > > > > > > ------------------------------------------------------------------------ > > > > -- > > fedora-selinux-list mailing list > > fedora-selinux-list at redhat.com > > https://www.redhat.com/mailman/listinfo/fedora-selinux-list > > You probably need to create /etc/selinux/targeted/context/user1 and user2 > > Base these off of xguest > > I am not crazy about having home content variable between users, I think > this is a waste of time. Others disagree. > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list > -------------- next part -------------- An HTML attachment was scrubbed... URL: From domg472 at gmail.com Tue Sep 15 20:14:48 2009 From: domg472 at gmail.com (Dominick Grift) Date: Tue, 15 Sep 2009 22:14:48 +0200 Subject: SELinux: creating a per-user confined domain In-Reply-To: References: <200909151557.45860.roberto.sassu@polito.it> <4AAFB58B.90002@redhat.com> Message-ID: <20090915201445.GC2579@notebook3.grift.internal> On Tue, Sep 15, 2009 at 08:30:43PM +0200, Roberto Sassu wrote: > Thanks all for replies. > I have modified the policy by using the template > userdom_unpriv_user_template() and everything is ok. > Talking about different labels for each home directory i'm not sure but if > all users domains have access to the default type user_home_dir_t > access control on files under /home will be based on DAC mechanism. > My effort is focused on trying to evaluate if it is possible with SELinux to > protect files using as criteria for access decision the combination user > identity-application-identity. > For example i want to protect the user's private key allowing the access > only to the program "ssh" ran by the user "user1". > In my policy i created the domain "user1_t" which is set by the login > program when "user1" logs in the system. Then i called the interface > ssh_basic_client_template(user1, user1_t, user1_r) which creates the derived > domain user1_ssh_t at the time user1 executes the "ssh" command. The file > $home/.ssh/id_rsa could be labeled with a unique label and a specific rule > can be added to allow only the user1_ssh_t domain to read the key. > Denying to users the ability to set security contexts, does this policy > create a separation between the ssh application and the others ran by the > same user? Well the ubac model/concept keeps selinux users processes/objects separated but it is not implemented in fedora. You could however implement similar functionality by using per role template but existing domains would have to be modified what a per role template does is create types derrived from the user domain prefix so $1_ssh_t, $1_ssh_home_t and thenlets you define rules like: allow $1_ssh_t $1_ssh_home_t:file read > > > > > > > > On Tue, Sep 15, 2009 at 5:40 PM, Daniel J Walsh wrote: > > > On 09/15/2009 09:57 AM, Roberto Sassu wrote: > > > Hello all > > > > > > i'm new to SELinux. I'm trying to create per-user domains in a system > > running > > > Fedora 11 with the targeted policy enabled. The reason for that is that i > > need > > > to create transitions to different domains when users start the same > > > application. > > > I followed these steps: > > > - written my custom policy module(posted as attachment) in order to > > create new > > > roles user1_r, user2_r with the default domains user1_t and user2_t; > > > - added to the system new selinux users user1_u and user2_u; > > > - added to the system the new linux users user1 and user2; > > > - associated user1 with user1_u and user2 with user2_u; > > > - labeled home directories respectively with types user1_home_t and > > > user2_home_t > > > - created the two files user1_u and user2_u in > > > /etc/selinux/targeted/contexts/users; > > > > > > Then i tried to connect in local to the ssh server from root to the user1 > > but > > > it rejected the connection with this log messages (but no AVC warnings): > > > > > > Sep 15 15:39:19 seclab05 sshd[5014]: Accepted password for user1 from ::1 > > port > > > 53163 ssh2 > > > Sep 15 15:39:19 seclab05 sshd[5014]: pam_selinux(sshd:session): > > conversation > > > failed > > > Sep 15 15:39:19 seclab05 sshd[5014]: pam_selinux(sshd:session): No > > response to > > > query: Would you like to enter a security context? [N] > > > Sep 15 15:39:19 seclab05 sshd[5014]: pam_selinux(sshd:session): Unable to > > get > > > valid context for user1 > > > Sep 15 15:39:19 seclab05 sshd[5014]: pam_unix(sshd:session): session > > opened > > > for user user1 by (uid=0) > > > Sep 15 15:39:19 seclab05 sshd[5014]: error: PAM: pam_open_session(): > > > Authentication failure > > > Sep 15 15:39:19 seclab05 sshd[5014]: error: ssh_selinux_setup_pty: > > > security_compute_relabel: Invalid argument > > > > > > If putting the system in permissive mode the connection was successful > > but the > > > security context after login was: > > system_u:system_r:unconfined_t:s0-s0:c0.c1023 > > > Any suggestions? Thanks in advance. > > > > > > > > > > > > > > > ------------------------------------------------------------------------ > > > > > > -- > > > fedora-selinux-list mailing list > > > fedora-selinux-list at redhat.com > > > https://www.redhat.com/mailman/listinfo/fedora-selinux-list > > > > You probably need to create /etc/selinux/targeted/context/user1 and user2 > > > > Base these off of xguest > > > > I am not crazy about having home content variable between users, I think > > this is a waste of time. Others disagree. > > > > -- > > fedora-selinux-list mailing list > > fedora-selinux-list at redhat.com > > https://www.redhat.com/mailman/listinfo/fedora-selinux-list > > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From anmajumd at cisco.com Wed Sep 16 00:58:50 2009 From: anmajumd at cisco.com (Anamitra Dutta Majumdar (anmajumd)) Date: Tue, 15 Sep 2009 17:58:50 -0700 Subject: Unconfining root user in strict policy mode In-Reply-To: <4AAAB7C2.4030805@redhat.com> References: <4AA9D53B.3090503@ak.jp.nec.com> <4AAA40E2.2070804@redhat.com> <4EF101F7236DB443A8FABF8164BFBD0C086B7277@xmb-sjc-223.amer.cisco.com> <4AAAB7C2.4030805@redhat.com> Message-ID: <4EF101F7236DB443A8FABF8164BFBD0C087B20FA@xmb-sjc-223.amer.cisco.com> Hi Dan, Thanks for you response. We attempted to set ssh_sysadm_login to 1 in the booleans file for our strict policy. We also did an setsebool -P to turn on ssh_sysadm_login. We also modified the security context of root user to root:sysadm_r:sysadm_t. We see a couple of issues now 1. The value for ssh_sysadm_login is not persistent across reboots 2. Even when the ssh_sysadm_login is turned on we cannot login as root user The sealert messaged seem to indicate the following . What else do we need to do to get it working? [root at vos-cm98 ~]# sealert -l e7c8894d-a508-430a-a594-da2a693e585f Summary: SELinux is preventing sshd (sshd_t) "execute" to /lib/libdl-2.5.so (lib_t). Detailed Description: SELinux denied access requested by sshd. It is not expected that this access is required by sshd and this access may signal an intrusion attempt. It is also possible that the specific version or configuration of the application is causing it to require additional access. Allowing Access: Sometimes labeling problems can cause SELinux denials. You could try to restore the default system file context for /lib/libdl-2.5.so, restorecon -v '/lib/libdl-2.5.so' If this does not work, there is currently no automatic way to allow this access. Instead, you can generate a local policy module to allow this access - see FAQ (http://fedora.redhat.com/docs/selinux-faq-fc5/#id2961385) Or you can disable SELinux protection altogether. Disabling SELinux protection is not recommended. Please file a bug report (http://bugzilla.redhat.com/bugzilla/enter_bug.cgi) against this package. Additional Information: Source Context system_u:system_r:sshd_t:s0 Target Context system_u:object_r:lib_t:s0 Target Objects /lib/libdl-2.5.so [ file ] Source sshd Source Path /usr/sbin/sshd Port Host vos-cm98.cisco.com Source RPM Packages openssh-server-4.3p2-36.el5 Target RPM Packages glibc-2.5-42 Policy RPM selinux-policy-2.4.6-255.el5 Selinux Enabled True Policy Type strict MLS Enabled False Enforcing Mode Enforcing Plugin Name catchall_file Host Name vos-cm98.cisco.com Platform Linux vos-cm98.cisco.com 2.6.18-160.el5PAE #1 SMP Mon Jul 27 17:45:11 EDT 2009 i686 i686 Alert Count 3 First Seen Tue Sep 15 16:02:26 2009 Last Seen Tue Sep 15 17:51:19 2009 Local ID e7c8894d-a508-430a-a594-da2a693e585f Line Numbers Raw Audit Messages host=vos-cm98.cisco.com type=AVC msg=audit(1253062279.960:406): avc: denied { execute } for pid=4261 comm="sshd" path="/lib/libdl-2.5.so" dev=dm-0 ino=51413920 scontext=system_u:system_r:sshd_t tcontext=system_u:object_r:lib_t tclass=file host=vos-cm98.cisco.com type=SYSCALL msg=audit(1253062279.960:406): arch=40000003 syscall=192 success=no exit=-13 a0=0 a1=3078 a2=5 a3=802 items=0 ppid=3119 pid=4261 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="sshd" exe="/usr/sbin/sshd" subj=system_u:system_r:sshd_t key=(null) Thanks Anamitra -----Original Message----- From: Daniel J Walsh [mailto:dwalsh at redhat.com] Sent: Friday, September 11, 2009 1:49 PM To: Anamitra Dutta Majumdar (anmajumd) Subject: Re: Unconfining root user in strict policy mode On 09/11/2009 04:34 PM, Anamitra Dutta Majumdar (anmajumd) wrote: > > We need a way to unconfine the root user with the strict policy being > loaded in RHEL5.4. Currently with the strict policy the security > context for root user is root:staff_r:staff_t. > Is there a way to do so. > > > Thanks > Anamitra & Radha > > > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list > > There is no unconfined_t for Strict policy but you can set the root account to login as sysadm_t which is very close You have to turn on the ssh_sysadm_login if you want to login via ssh as sysadm_t And I think remove staff_r from root account will set it up to login as sysadm_r something like # semanage user -m -R"sysadm_r system_r" root From dwalsh at redhat.com Wed Sep 16 17:41:45 2009 From: dwalsh at redhat.com (Daniel J Walsh) Date: Wed, 16 Sep 2009 13:41:45 -0400 Subject: Unconfining root user in strict policy mode In-Reply-To: <4EF101F7236DB443A8FABF8164BFBD0C087B20FA@xmb-sjc-223.amer.cisco.com> References: <4AA9D53B.3090503@ak.jp.nec.com> <4AAA40E2.2070804@redhat.com> <4EF101F7236DB443A8FABF8164BFBD0C086B7277@xmb-sjc-223.amer.cisco.com> <4AAAB7C2.4030805@redhat.com> <4EF101F7236DB443A8FABF8164BFBD0C087B20FA@xmb-sjc-223.amer.cisco.com> Message-ID: <4AB12359.6090508@redhat.com> On 09/15/2009 08:58 PM, Anamitra Dutta Majumdar (anmajumd) wrote: > > Hi Dan, > > Thanks for you response. > > We attempted to set ssh_sysadm_login to 1 in the booleans file for our > strict policy. We also did an setsebool -P to turn on ssh_sysadm_login. > We also modified the security context of root user to > root:sysadm_r:sysadm_t. We see a couple of issues now > > 1. The value for ssh_sysadm_login is not persistent across reboots setsebool -P should persist >From the looks of it, you never relabeled when you switched to the strict policy. touch /.autorelabel reboot Make sure you boot in permissive mode (Kernel option "enforcing=0") > 2. Even when the ssh_sysadm_login is turned on we cannot login as root > user > > The sealert messaged seem to indicate the following . What else do we > need to do to get it working? > > [root at vos-cm98 ~]# sealert -l e7c8894d-a508-430a-a594-da2a693e585f > > Summary: > > SELinux is preventing sshd (sshd_t) "execute" to /lib/libdl-2.5.so > (lib_t). > > Detailed Description: > > SELinux denied access requested by sshd. It is not expected that this > access is > required by sshd and this access may signal an intrusion attempt. It is > also > possible that the specific version or configuration of the application > is > causing it to require additional access. > > Allowing Access: > > Sometimes labeling problems can cause SELinux denials. You could try to > restore > the default system file context for /lib/libdl-2.5.so, > > restorecon -v '/lib/libdl-2.5.so' > > If this does not work, there is currently no automatic way to allow this > access. > Instead, you can generate a local policy module to allow this access - > see FAQ > (http://fedora.redhat.com/docs/selinux-faq-fc5/#id2961385) Or you can > disable > SELinux protection altogether. Disabling SELinux protection is not > recommended. > Please file a bug report > (http://bugzilla.redhat.com/bugzilla/enter_bug.cgi) > against this package. > > Additional Information: > > Source Context system_u:system_r:sshd_t:s0 > Target Context system_u:object_r:lib_t:s0 > Target Objects /lib/libdl-2.5.so [ file ] > Source sshd > Source Path /usr/sbin/sshd > Port > Host vos-cm98.cisco.com > Source RPM Packages openssh-server-4.3p2-36.el5 > Target RPM Packages glibc-2.5-42 > Policy RPM selinux-policy-2.4.6-255.el5 > Selinux Enabled True > Policy Type strict > MLS Enabled False > Enforcing Mode Enforcing > Plugin Name catchall_file > Host Name vos-cm98.cisco.com > Platform Linux vos-cm98.cisco.com 2.6.18-160.el5PAE > #1 SMP > Mon Jul 27 17:45:11 EDT 2009 i686 i686 > Alert Count 3 > First Seen Tue Sep 15 16:02:26 2009 > Last Seen Tue Sep 15 17:51:19 2009 > Local ID e7c8894d-a508-430a-a594-da2a693e585f > Line Numbers > > Raw Audit Messages > > host=vos-cm98.cisco.com type=AVC msg=audit(1253062279.960:406): avc: > denied { execute } for pid=4261 comm="sshd" path="/lib/libdl-2.5.so" > dev=dm-0 ino=51413920 scontext=system_u:system_r:sshd_t > tcontext=system_u:object_r:lib_t tclass=file > > host=vos-cm98.cisco.com type=SYSCALL msg=audit(1253062279.960:406): > arch=40000003 syscall=192 success=no exit=-13 a0=0 a1=3078 a2=5 a3=802 > items=0 ppid=3119 pid=4261 auid=4294967295 uid=0 gid=0 euid=0 suid=0 > fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="sshd" > exe="/usr/sbin/sshd" subj=system_u:system_r:sshd_t key=(null) > > > Thanks > Anamitra > > > -----Original Message----- > From: Daniel J Walsh [mailto:dwalsh at redhat.com] > Sent: Friday, September 11, 2009 1:49 PM > To: Anamitra Dutta Majumdar (anmajumd) > Subject: Re: Unconfining root user in strict policy mode > > On 09/11/2009 04:34 PM, Anamitra Dutta Majumdar (anmajumd) wrote: >> >> We need a way to unconfine the root user with the strict policy being >> loaded in RHEL5.4. Currently with the strict policy the security >> context for root user is root:staff_r:staff_t. >> Is there a way to do so. >> >> >> Thanks >> Anamitra & Radha >> >> >> >> -- >> fedora-selinux-list mailing list >> fedora-selinux-list at redhat.com >> https://www.redhat.com/mailman/listinfo/fedora-selinux-list >> >> > There is no unconfined_t for Strict policy but you can set the root > account to login as sysadm_t which is very close > > You have to turn on the ssh_sysadm_login if you want to login via ssh as > sysadm_t > > And I think remove staff_r from root account will set it up to login as > sysadm_r > > something like > > # semanage user -m -R"sysadm_r system_r" root From tibbs at math.uh.edu Fri Sep 18 04:06:15 2009 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Thu, 17 Sep 2009 23:06:15 -0500 Subject: Confusion about transition when httpd_t process calls sendmail Message-ID: Tough to come up with a subject for this one; it's really messing with my fragile mind. I have a system running RT3, which uses mod_perl or somesuch to run within the web server process. It needs to send mail, so it calls /usr/bin/sendmail, which happens to be exim on this system. If I understand things correctly, the sendmail process is supposed to start as or somehow transition to exim_t where it is then allowed to access whatever exim_t is allowed to access. This was all working until I had to reboot the machine for unrelated reasons today. Now, RT3 can't send mail, and the audit logs seem to indicate that httpd_t is being denied things like writing to the exim spool file location. It really seems like somehow the transition to exim_t is not happening. Perhaps this will illustrate: > s ausearch -ts today |grep exim|audit2allow #============= httpd_t ============== allow httpd_t exim_spool_t:dir { search setattr read write getattr remove_name open add_name }; allow httpd_t exim_spool_t:file { rename setattr read lock create write getattr unlink open append }; allow httpd_t proc_net_t:file { read getattr open }; allow httpd_t self:capability fowner; allow httpd_t smtp_port_t:tcp_socket name_connect; Currently I've simply disabled selinux until I can understand what has happened. yum.log indicates that selinux-policy(-targeted) were updated on the 13th, but everything was working fine up until the today's reboot. No other related packages have been updated recently, and nothing was updated today. I suppose the reboot did boot me into a new kernel version (from kernel-2.6.29.6-217.2.3.fc11.x86_64 to kernel-2.6.30.5-43.fc11.x86_64). > ls -lZ /usr/sbin/exim -rwsr-xr-x. root root system_u:object_r:exim_exec_t:s0 /usr/sbin/exim* (which is what /usr/bin/sendmail is linked to via half a dozen symlinks due to alternatives). - J< From paul at city-fan.org Fri Sep 18 06:46:00 2009 From: paul at city-fan.org (Paul Howarth) Date: Fri, 18 Sep 2009 07:46:00 +0100 Subject: Confusion about transition when httpd_t process calls sendmail In-Reply-To: References: Message-ID: <20090918074600.57bc330c@metropolis.intra.city-fan.org> On Thu, 17 Sep 2009 23:06:15 -0500 Jason L Tibbitts III wrote: > Tough to come up with a subject for this one; it's really messing with > my fragile mind. I have a system running RT3, which uses mod_perl or > somesuch to run within the web server process. It needs to send mail, > so it calls /usr/bin/sendmail, which happens to be exim on this > system. If I understand things correctly, the sendmail process is > supposed to start as or somehow transition to exim_t where it is then > allowed to access whatever exim_t is allowed to access. > > This was all working until I had to reboot the machine for unrelated > reasons today. Now, RT3 can't send mail, and the audit logs seem to > indicate that httpd_t is being denied things like writing to the exim > spool file location. It really seems like somehow the transition to > exim_t is not happening. Perhaps this will illustrate: > > > s ausearch -ts today |grep exim|audit2allow > > #============= httpd_t ============== > allow httpd_t exim_spool_t:dir { search setattr read write getattr > remove_name open add_name }; allow httpd_t exim_spool_t:file { rename > setattr read lock create write getattr unlink open append }; allow > httpd_t proc_net_t:file { read getattr open }; allow httpd_t > self:capability fowner; allow httpd_t smtp_port_t:tcp_socket > name_connect; > > Currently I've simply disabled selinux until I can understand what has > happened. yum.log indicates that selinux-policy(-targeted) were > updated on the 13th, but everything was working fine up until the > today's reboot. No other related packages have been updated > recently, and nothing was updated today. I suppose the reboot did > boot me into a new kernel version (from > kernel-2.6.29.6-217.2.3.fc11.x86_64 to > kernel-2.6.30.5-43.fc11.x86_64). > > > ls -lZ /usr/sbin/exim > -rwsr-xr-x. root root system_u:object_r:exim_exec_t:s0 /usr/sbin/exim* > > (which is what /usr/bin/sendmail is linked to via half a dozen > symlinks due to alternatives). Just a thought but is your httpd_can_sendmail boolean still set? Paul. From dwalsh at redhat.com Fri Sep 18 12:26:08 2009 From: dwalsh at redhat.com (Daniel J Walsh) Date: Fri, 18 Sep 2009 08:26:08 -0400 Subject: Confusion about transition when httpd_t process calls sendmail In-Reply-To: <20090918074600.57bc330c@metropolis.intra.city-fan.org> References: <20090918074600.57bc330c@metropolis.intra.city-fan.org> Message-ID: <4AB37C60.10508@redhat.com> On 09/18/2009 02:46 AM, Paul Howarth wrote: > On Thu, 17 Sep 2009 23:06:15 -0500 > Jason L Tibbitts III wrote: > >> Tough to come up with a subject for this one; it's really messing with >> my fragile mind. I have a system running RT3, which uses mod_perl or >> somesuch to run within the web server process. It needs to send mail, >> so it calls /usr/bin/sendmail, which happens to be exim on this >> system. If I understand things correctly, the sendmail process is >> supposed to start as or somehow transition to exim_t where it is then >> allowed to access whatever exim_t is allowed to access. >> >> This was all working until I had to reboot the machine for unrelated >> reasons today. Now, RT3 can't send mail, and the audit logs seem to >> indicate that httpd_t is being denied things like writing to the exim >> spool file location. It really seems like somehow the transition to >> exim_t is not happening. Perhaps this will illustrate: >> >>> s ausearch -ts today |grep exim|audit2allow >> >> #============= httpd_t ============== >> allow httpd_t exim_spool_t:dir { search setattr read write getattr >> remove_name open add_name }; allow httpd_t exim_spool_t:file { rename >> setattr read lock create write getattr unlink open append }; allow >> httpd_t proc_net_t:file { read getattr open }; allow httpd_t >> self:capability fowner; allow httpd_t smtp_port_t:tcp_socket >> name_connect; >> >> Currently I've simply disabled selinux until I can understand what has >> happened. yum.log indicates that selinux-policy(-targeted) were >> updated on the 13th, but everything was working fine up until the >> today's reboot. No other related packages have been updated >> recently, and nothing was updated today. I suppose the reboot did >> boot me into a new kernel version (from >> kernel-2.6.29.6-217.2.3.fc11.x86_64 to >> kernel-2.6.30.5-43.fc11.x86_64). >> >>> ls -lZ /usr/sbin/exim >> -rwsr-xr-x. root root system_u:object_r:exim_exec_t:s0 /usr/sbin/exim* >> >> (which is what /usr/bin/sendmail is linked to via half a dozen >> symlinks due to alternatives). > > Just a thought but is your httpd_can_sendmail boolean still set? > > Paul. > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list > > I think if people would just get their hands around this document, it could help. http://people.fedoraproject.org/~dwalsh/SELinux/Presentations/selinux_four_things.pdf SELinux is trying to say either you have a labeling problem in that exim no longer has the correct label. So httpd_t is not transitioning to the system_mail_t. Or For some reason the http_can_sendmail boolean is not set. Of cours it could also be a bug in policy. From tibbs at math.uh.edu Fri Sep 18 16:23:40 2009 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Fri, 18 Sep 2009 11:23:40 -0500 Subject: Confusion about transition when httpd_t process calls sendmail In-Reply-To: <20090918074600.57bc330c@metropolis.intra.city-fan.org> (Paul Howarth's message of "Fri, 18 Sep 2009 07:46:00 +0100") References: <20090918074600.57bc330c@metropolis.intra.city-fan.org> Message-ID: >>>>> "PH" == Paul Howarth writes: PH> Just a thought but is your httpd_can_sendmail boolean still set? Well, crap, it's off. I thought setting booleans was supposed to be permanent, but I guess you have to pass a flag and I suppose I might not have. Is there a way to check if any currently set booleans are not set permanently? - J< From paul at city-fan.org Fri Sep 18 19:41:50 2009 From: paul at city-fan.org (Paul Howarth) Date: Fri, 18 Sep 2009 20:41:50 +0100 Subject: Confusion about transition when httpd_t process calls sendmail In-Reply-To: References: <20090918074600.57bc330c@metropolis.intra.city-fan.org> Message-ID: <20090918204150.640b491b@metropolis.intra.city-fan.org> On Fri, 18 Sep 2009 11:23:40 -0500 Jason L Tibbitts III wrote: > >>>>> "PH" == Paul Howarth writes: > > PH> Just a thought but is your httpd_can_sendmail boolean still set? > > Well, crap, it's off. I thought setting booleans was supposed to be > permanent, but I guess you have to pass a flag and I suppose I might > not have. Is there a way to check if any currently set booleans are > not set permanently? I think permanently set booleans are recorded in /etc/selinux/targeted/modules/active/booleans.local but I may be wrong about that. You need to use setsebool -P to set them permanently. Paul. From tibbs at math.uh.edu Sat Sep 19 00:07:35 2009 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Fri, 18 Sep 2009 19:07:35 -0500 Subject: Confusion about transition when httpd_t process calls sendmail In-Reply-To: (Jason L. Tibbitts, III's message of "Fri, 18 Sep 2009 11:23:40 -0500") References: <20090918074600.57bc330c@metropolis.intra.city-fan.org> Message-ID: OK, so what's confused me the most, I think, is that a naive interpretation of httpd_can_sendmail is that calls to sendmail will simply fail when it's off. Instead, the context transition just fails to happen, leading to the sendmail binary running with the wrong context and generating errors that make it look as if the MTA is misconfigured. Anyway, problem solved and information saved for posterity. If, however, there's interest in making this failure less baffling to novices, consider actually failing when httpd calls sendmail instead of simply disabling the change of context (if that's even possible; I've no idea). - J< From fedora03 at grifent.com Wed Sep 23 14:47:50 2009 From: fedora03 at grifent.com (John Griffiths) Date: Wed, 23 Sep 2009 10:47:50 -0400 Subject: Two AVCs Message-ID: <4ABA3516.9070106@grifent.com> An HTML attachment was scrubbed... URL: From dwalsh at redhat.com Wed Sep 23 14:57:03 2009 From: dwalsh at redhat.com (Daniel J Walsh) Date: Wed, 23 Sep 2009 07:57:03 -0700 Subject: Two AVCs In-Reply-To: <4ABA3516.9070106@grifent.com> References: <4ABA3516.9070106@grifent.com> Message-ID: <4ABA373F.2090709@redhat.com> On 09/23/2009 07:47 AM, John Griffiths wrote: > I am using selinux-policy-targeted-3.5.13-71.fc10.noarch on Fedora 10. I am > getting these AVCs. They do not seem to inhibit functionality but still > troublesome to get the selinux alerts all the time. Are these bugs in the policy > or something that will not be addressed and I need to generate local policy? > > 1) SELinux is preventing postdrop (postfix_postdrop_t) "getattr" httpd_t. > > Raw Audit Messages : > > node=elijah.suretrak21.net type=AVC msg=audit(1253716264.867:65886): avc: > denied { getattr } for pid=30094 comm="postdrop" path="pipe:[2618550]" > dev=pipefs ino=2618550 scontext=system_u:system_r:postfix_postdrop_t:s0 > tcontext=system_u:system_r:httpd_t:s0 tclass=fifo_file > > node=elijah.suretrak21.net type=SYSCALL msg=audit(1253716264.867:65886): > arch=40000003 syscall=197 success=no exit=-13 a0=2 a1=bfc167c8 a2=94eff4 > a3=2 items=0 ppid=30093 pid=30094 auid=4294967295 uid=48 gid=48 euid=48 > suid=48 fsuid=48 egid=90 sgid=90 fsgid=90 tty=(none) ses=4294967295 > comm="postdrop" exe="/usr/sbin/postdrop" > subj=system_u:system_r:postfix_postdrop_t:s0 key=(null) This seems a little strange, is postfix being executed from apache? I would guess that postfix does not communicate with apache via fifo_file, so might be a leak. > > 2) SELinux is preventing sendmail (system_mail_t) "read" to > /usr/share/GeoIP/GeoIP.dat (usr_t). > > Raw Audit Messages : > > node=elijah.suretrak21.net type=AVC msg=audit(1253643380.763:60806): avc: > denied { read } for pid=1311 comm="sendmail" > path="/usr/share/GeoIP/GeoIP.dat" dev=dm-0 ino=663651 > scontext=system_u:system_r:system_mail_t:s0 > tcontext=system_u:object_r:usr_t:s0 tclass=file > > node=elijah.suretrak21.net type=SYSCALL msg=audit(1253643380.763:60806): > arch=40000003 syscall=11 success=yes exit=0 a0=9ad05d0 a1=9acfd18 a2=9acfb08 > a3=0 items=0 ppid=14784 pid=1311 auid=4294967295 uid=48 gid=48 euid=48 > suid=48 fsuid=48 egid=48 sgid=48 fsgid=48 tty=(none) ses=4294967295 > comm="sendmail" exe="/usr/sbin/sendmail.postfix" > subj=system_u:system_r:system_mail_t:s0 key=(null) > This one looks like a leak unless something is actually trying to mail /usr/share/GeoIP/GeoIP.dat > Regards, > John Griffiths > > > ------------------------------------------------------------------------ > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list You can add custom policy to allow these by executing audit2allow -M mypol From paul at city-fan.org Wed Sep 23 15:11:14 2009 From: paul at city-fan.org (Paul Howarth) Date: Wed, 23 Sep 2009 16:11:14 +0100 Subject: Two AVCs In-Reply-To: <4ABA373F.2090709@redhat.com> References: <4ABA3516.9070106@grifent.com> <4ABA373F.2090709@redhat.com> Message-ID: <20090923161114.61431028@metropolis.intra.city-fan.org> On Wed, 23 Sep 2009 07:57:03 -0700 Daniel J Walsh wrote: > On 09/23/2009 07:47 AM, John Griffiths wrote: > > 2) SELinux is preventing sendmail (system_mail_t) "read" to > > /usr/share/GeoIP/GeoIP.dat (usr_t). > > > > Raw Audit Messages : > > > > node=elijah.suretrak21.net type=AVC > > msg=audit(1253643380.763:60806): avc: denied { read } for pid=1311 > > comm="sendmail" path="/usr/share/GeoIP/GeoIP.dat" dev=dm-0 > > ino=663651 scontext=system_u:system_r:system_mail_t:s0 > > tcontext=system_u:object_r:usr_t:s0 tclass=file > > > > node=elijah.suretrak21.net type=SYSCALL > > msg=audit(1253643380.763:60806): arch=40000003 syscall=11 > > success=yes exit=0 a0=9ad05d0 a1=9acfd18 a2=9acfb08 a3=0 items=0 > > ppid=14784 pid=1311 auid=4294967295 uid=48 gid=48 euid=48 suid=48 > > fsuid=48 egid=48 sgid=48 fsgid=48 tty=(none) ses=4294967295 > > comm="sendmail" exe="/usr/sbin/sendmail.postfix" > > subj=system_u:system_r:system_mail_t:s0 key=(null) > > > This one looks like a leak unless something is actually trying to > mail /usr/share/GeoIP/GeoIP.dat Are you using milter-greylist by any chance? Paul. From fedora03 at grifent.com Wed Sep 23 15:39:51 2009 From: fedora03 at grifent.com (John Griffiths) Date: Wed, 23 Sep 2009 11:39:51 -0400 Subject: Two AVCs In-Reply-To: <20090923161114.61431028@metropolis.intra.city-fan.org> References: <4ABA3516.9070106@grifent.com> <4ABA373F.2090709@redhat.com> <20090923161114.61431028@metropolis.intra.city-fan.org> Message-ID: <4ABA4147.8030006@grifent.com> An HTML attachment was scrubbed... URL: From fedora03 at grifent.com Wed Sep 23 16:00:18 2009 From: fedora03 at grifent.com (John Griffiths) Date: Wed, 23 Sep 2009 12:00:18 -0400 Subject: Two AVCs In-Reply-To: <4ABA373F.2090709@redhat.com> References: <4ABA3516.9070106@grifent.com> <4ABA373F.2090709@redhat.com> Message-ID: <4ABA4612.9070800@grifent.com> An HTML attachment was scrubbed... URL: From BGinn at beyondtrust.com Wed Sep 23 16:35:40 2009 From: BGinn at beyondtrust.com (Brian Ginn) Date: Wed, 23 Sep 2009 09:35:40 -0700 Subject: How can I use an selinux unused port Message-ID: <8F43ACC6DCEECD4FA252B8042E2C4B8BA072E278EF@dragonfly.symark.com> I want to use port 60000 for a confined application that is not postgrey. However port 60000 is "owned by" postgrey and I can't seem to get past that. I don't want to add SELinux policy that allows my app to use postgrey's port, I want my app to think the port is myapp_port_t. Is there a way to free port 60000 from postgrey? [root at domingo install]# netstat -an | grep 60000 [root at domingo install]# semanage port -l | grep 60000 postgrey_port_t tcp 60000 [root at domingo install]# /usr/sbin/semanage port -d -t postgrey_port_t -p tcp 60000 /usr/sbin/semanage: Port tcp/60000 is defined in policy, cannot be deleted [root at domingo install]# Thanks, Brian ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ -------------- next part -------------- An HTML attachment was scrubbed... URL: From bruno at wolff.to Wed Sep 23 17:20:20 2009 From: bruno at wolff.to (Bruno Wolff III) Date: Wed, 23 Sep 2009 12:20:20 -0500 Subject: New equivalent to browser_confine_xguest? Message-ID: <20090923172020.GA18474@wolff.to> There used to be a boolean browser_confine_xguest, but there no longer is. Is there a simple way to not let firefox connect to the network when run by an xguest user? From paul at city-fan.org Thu Sep 24 08:43:57 2009 From: paul at city-fan.org (Paul Howarth) Date: Thu, 24 Sep 2009 09:43:57 +0100 Subject: Logging with bind-chroot Message-ID: <4ABB314D.5070209@city-fan.org> Today's update of bind in F11 suggests adding this line to /etc/rsyslog.conf to maintain logging with a chroot-ed bind: $AddUnixListenSocket /var/named/chroot/dev/log For this to work on F-11, I needed to add the following policy module: :::::::::::::: mybindchroot.fc :::::::::::::: /var/named/chroot/dev -d gen_context(system_u:object_r:device_t,s0) /var/named/chroot/dev/log -s gen_context(system_u:object_r:devlog_t,s0) :::::::::::::: mybindchroot.te :::::::::::::: policy_module(mybindchroot, 0.0.4) require { type syslogd_t; } # rsyslog needs to search the bind chroot when creating # /dev/log in the chroot bind_search_cache(syslogd_t) I'd expect the same to apply in other releases too. Paul. From domg472 at gmail.com Thu Sep 24 09:32:45 2009 From: domg472 at gmail.com (Dominick Grift) Date: Thu, 24 Sep 2009 11:32:45 +0200 Subject: How can I use an selinux unused port In-Reply-To: <8F43ACC6DCEECD4FA252B8042E2C4B8BA072E278EF@dragonfly.symark.com> References: <8F43ACC6DCEECD4FA252B8042E2C4B8BA072E278EF@dragonfly.symark.com> Message-ID: <20090924093239.GA2778@notebook3.grift.internal> On Wed, Sep 23, 2009 at 09:35:40AM -0700, Brian Ginn wrote: > I want to use port 60000 for a confined application that is not postgrey. > > However port 60000 is "owned by" postgrey and I can't seem to get past that. > > I don't want to add SELinux policy that allows my app to use postgrey's port, > > I want my app to think the port is myapp_port_t. > > > > Is there a way to free port 60000 from postgrey? No easy way no, the port is declared in the corenetwork source policy which is compiled in the base module. You cannot alter/remove policy that is defined in base without editing rebuilding the whole thing. You would have to get the selinux-policy.src.rpm corresponding to what you have installed, prep it (apply patch), Than in corenetwork.te.in remove the declaration for the particular port , rebuild and reinstall it. But why not share the port with postgrey? Only one service can bind to it at a time anyways. Other objects get shared all the time. > > > > [root at domingo install]# netstat -an | grep 60000 > > [root at domingo install]# semanage port -l | grep 60000 > > postgrey_port_t tcp 60000 > > [root at domingo install]# /usr/sbin/semanage port -d -t postgrey_port_t -p tcp 60000 > > /usr/sbin/semanage: Port tcp/60000 is defined in policy, cannot be deleted > > [root at domingo install]# > > > > > > > > Thanks, > > Brian > > > ______________________________________________________________________ > This email has been scanned by the MessageLabs Email Security System. > For more information please visit http://www.messagelabs.com/email > ______________________________________________________________________ > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From tarnai_t at yahoo.de Fri Sep 25 15:35:52 2009 From: tarnai_t at yahoo.de (tarnait) Date: Fri, 25 Sep 2009 15:35:52 +0000 (GMT) Subject: Dear List members Message-ID: <708302.79400.qm@web24104.mail.ird.yahoo.com> Hi, I'm new to SElinux and I'm a bit careful with it, so up till now I want to run it in permissive mode. After reading a lot's of docs I fixed most of my problems, but there are still some errors in audit.log. Now I would like to ask you to review this errors and give me feedback if this rules are safe to add to my policy or not. In summary is my understanding correct that: O auditctl, ifconfig, iptables-restor, dmesg and pppd try to write to the console, O pppd searches something in the root home directory ??!, O and iptables writes to a socket? if I would add this policy to the module wouldn't it be too much (e.g. could for example pppd access all my files?) Thanks for the answers, Kind Regards, Tibor type=AVC msg=audit(1253870573.883:13): avc: denied { read write } for pid=877 comm="auditctl" name="console" dev=sda1 ino=15533 scontext=system_u:system_r:auditctl_t:s0 tcontext=system_u:object_r:file_t:s0 tclass=chr_file Was caused by: Missing type enforcement (TE) allow rule. You can use audit2allow to generate a loadable module to allow this access. type=AVC msg=audit(1253870574.190:15): avc: denied { read write } for pid=918 comm="ifconfig" name="console" dev=sda1 ino=15533 scontext=system_u:system_r:ifconfig_t:s0 tcontext=system_u:object_r:file_t:s0 tclass=chr_file Was caused by: Missing type enforcement (TE) allow rule. You can use audit2allow to generate a loadable module to allow this access. type=AVC msg=audit(1253870574.264:16): avc: denied { read write } for pid=921 comm="pppd" name="console" dev=sda1 ino=15533 scontext=system_u:system_r:pppd_t:s0 tcontext=system_u:object_r:file_t:s0 tclass=chr_file Was caused by: Missing type enforcement (TE) allow rule. You can use audit2allow to generate a loadable module to allow this access. type=AVC msg=audit(1253870574.325:17): avc: denied { search } for pid=921 comm="pppd" name="root" dev=sda1 ino=12 scontext=system_u:system_r:pppd_t:s0 tcontext=unconfined_u:object_r:unconfined_home_dir_t:s0 tclass=dir Was caused by: Missing type enforcement (TE) allow rule. You can use audit2allow to generate a loadable module to allow this access. type=AVC msg=audit(1253870574.401:18): avc: denied { read write } for pid=929 comm="iptables-restor" name="console" dev=sda1 ino=15533 scontext=system_u:system_r:iptables_t:s0 tcontext=system_u:object_r:file_t:s0 tclass=chr_file Was caused by: Missing type enforcement (TE) allow rule. You can use audit2allow to generate a loadable module to allow this access. type=AVC msg=audit(1253870576.482:19): avc: denied { read write } for pid=1087 comm="dmesg" name="console" dev=sda1 ino=15533 scontext=system_u:system_r:dmesg_t:s0 tcontext=system_u:object_r:file_t:s0 tclass=chr_file Was caused by: Missing type enforcement (TE) allow rule. You can use audit2allow to generate a loadable module to allow this access. type=AVC msg=audit(1253870578.829:20): avc: denied { read write } for pid=1242 comm="iptables" path="socket:[3131]" dev=sockfs ino=3131 scontext=system_u:system_r:iptables_t:s0 tcontext=system_u:system_r:pppd_t:s0 tclass=packet_socket Was caused by: Missing type enforcement (TE) allow rule. You can use audit2allow to generate a loadable module to allow this access. -------------- next part -------------- An HTML attachment was scrubbed... URL: From domg472 at gmail.com Fri Sep 25 16:38:20 2009 From: domg472 at gmail.com (Dominick Grift) Date: Fri, 25 Sep 2009 18:38:20 +0200 Subject: Dear List members In-Reply-To: <708302.79400.qm@web24104.mail.ird.yahoo.com> References: <708302.79400.qm@web24104.mail.ird.yahoo.com> Message-ID: <20090925163818.GA14076@notebook3.grift.internal> On Fri, Sep 25, 2009 at 03:35:52PM +0000, tarnait wrote: > > > Hi, > > I'm new to SElinux and I'm a bit careful with it, so up till now I want to run it in permissive mode. After reading a lot's of docs I fixed most of my problems, but there are still some errors in audit.log. Now I would like to ask you to review this errors and give me feedback if this rules are safe to add to my policy or not. In summary is my understanding correct that: > > O auditctl, ifconfig, iptables-restor, dmesg and pppd try to write to the console, > O pppd searches something in the root home directory ??!, > O and iptables writes to a socket? > > if I would add this policy to the module wouldn't it be too much (e.g. could for example pppd access all my files?) > > Thanks for the answers, > Kind Regards, Tibor > > > type=AVC msg=audit(1253870573.883:13): avc: denied { read write } for pid=877 comm="auditctl" name="console" dev=sda1 ino=15533 scontext=system_u:system_r:auditctl_t:s0 tcontext=system_u:object_r:file_t:s0 tclass=chr_file > Was caused by: > Missing type enforcement (TE) allow rule. > > You can use audit2allow to generate a loadable module to allow this access. > > type=AVC msg=audit(1253870574.190:15): avc: denied { read write } for pid=918 comm="ifconfig" name="console" dev=sda1 ino=15533 scontext=system_u:system_r:ifconfig_t:s0 tcontext=system_u:object_r:file_t:s0 tclass=chr_file > Was caused by: > Missing type enforcement (TE) allow rule. > > You can use audit2allow to generate a loadable module to allow this access. > > type=AVC msg=audit(1253870574.264:16): avc: denied { read write } for pid=921 comm="pppd" name="console" dev=sda1 ino=15533 scontext=system_u:system_r:pppd_t:s0 tcontext=system_u:object_r:file_t:s0 tclass=chr_file > Was caused by: > Missing type enforcement (TE) allow rule. > > You can use audit2allow to generate a loadable module to allow this access. The rules above should not be allowed because the /dev/console has an invalid type (file_t) This signals a labelling issue: http://docs.fedoraproject.org/selinux-user-guide/f11/en-US/sect-Security-Enhanced_Linux-Working_with_SELinux-The_file_t_and_default_t_Types.html > > type=AVC msg=audit(1253870574.325:17): avc: denied { search } for pid=921 comm="pppd" name="root" dev=sda1 ino=12 scontext=system_u:system_r:pppd_t:s0 tcontext=unconfined_u:object_r:unconfined_home_dir_t:s0 tclass=dir > Was caused by: > Missing type enforcement (TE) allow rule. > > You can use audit2allow to generate a loadable module to allow this access. > This also *may* be a labelling issue. pppd wants to search /root dir. /root dir has type unconfined_home_dir_t. see if this is correct: matchpathcon /root restorecon -R /root /root usually has type admin_home_t and i do not see any good reason why pppd should be able to search it. misconfiguration/misusage maybe? > type=AVC msg=audit(1253870574.401:18): avc: denied { read write } for pid=929 comm="iptables-restor" name="console" dev=sda1 ino=15533 scontext=system_u:system_r:iptables_t:s0 tcontext=system_u:object_r:file_t:s0 tclass=chr_file > Was caused by: > Missing type enforcement (TE) allow rule. > > You can use audit2allow to generate a loadable module to allow this access. > > type=AVC msg=audit(1253870576.482:19): avc: denied { read write } for pid=1087 comm="dmesg" name="console" dev=sda1 ino=15533 scontext=system_u:system_r:dmesg_t:s0 tcontext=system_u:object_r:file_t:s0 tclass=chr_file > Was caused by: > Missing type enforcement (TE) allow rule. > > You can use audit2allow to generate a loadable module to allow this access. > > type=AVC msg=audit(1253870578.829:20): avc: denied { read write } for pid=1242 comm="iptables" path="socket:[3131]" dev=sockfs ino=3131 scontext=system_u:system_r:iptables_t:s0 tcontext=system_u:system_r:pppd_t:s0 tclass=packet_socket > Was caused by: > Missing type enforcement (TE) allow rule. > > You can use audit2allow to generate a loadable module to allow this access. > > > Not sure about this one. Maybe signals a leaked file descriptor? I can tell you that on my configuration this access is not allowed. What distro, kernel and selinux version are you using? > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From dwalsh at redhat.com Fri Sep 25 20:41:26 2009 From: dwalsh at redhat.com (Daniel J Walsh) Date: Fri, 25 Sep 2009 13:41:26 -0700 Subject: How can I use an selinux unused port In-Reply-To: <20090924093239.GA2778@notebook3.grift.internal> References: <8F43ACC6DCEECD4FA252B8042E2C4B8BA072E278EF@dragonfly.symark.com> <20090924093239.GA2778@notebook3.grift.internal> Message-ID: <4ABD2AF6.7050304@redhat.com> On 09/24/2009 02:32 AM, Dominick Grift wrote: > On Wed, Sep 23, 2009 at 09:35:40AM -0700, Brian Ginn wrote: >> I want to use port 60000 for a confined application that is not postgrey. >> >> However port 60000 is "owned by" postgrey and I can't seem to get past that. >> >> I don't want to add SELinux policy that allows my app to use postgrey's port, >> >> I want my app to think the port is myapp_port_t. >> >> >> Is there a way to free port 60000 from postgrey? > > No easy way no, the port is declared in the corenetwork source policy which is compiled in the base module. You cannot alter/remove policy that is defined in base without editing rebuilding the whole thing. > > You would have to get the selinux-policy.src.rpm corresponding to what you have installed, prep it (apply patch), Than in corenetwork.te.in remove the declaration for the particular port , rebuild and reinstall it. > > But why not share the port with postgrey? Only one service can bind to it at a time anyways. Other objects get shared all the time. > >> >> >> >> [root at domingo install]# netstat -an | grep 60000 >> >> [root at domingo install]# semanage port -l | grep 60000 >> >> postgrey_port_t tcp 60000 >> >> [root at domingo install]# /usr/sbin/semanage port -d -t postgrey_port_t -p tcp 60000 >> >> /usr/sbin/semanage: Port tcp/60000 is defined in policy, cannot be deleted >> >> [root at domingo install]# >> >> >> >> I agree, your best choice is to just let your app user postgrey_port_t >> >> >> >> Thanks, >> >> Brian >> >> >> ______________________________________________________________________ >> This email has been scanned by the MessageLabs Email Security System. >> For more information please visit http://www.messagelabs.com/email >> ______________________________________________________________________ > >> -- >> fedora-selinux-list mailing list >> fedora-selinux-list at redhat.com >> https://www.redhat.com/mailman/listinfo/fedora-selinux-list > > > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list From paul at city-fan.org Sat Sep 26 00:10:58 2009 From: paul at city-fan.org (Paul Howarth) Date: Sat, 26 Sep 2009 01:10:58 +0100 Subject: Dear List members In-Reply-To: <20090925163818.GA14076@notebook3.grift.internal> References: <708302.79400.qm@web24104.mail.ird.yahoo.com> <20090925163818.GA14076@notebook3.grift.internal> Message-ID: <20090926011058.3b85d5d5@metropolis.intra.city-fan.org> On Fri, 25 Sep 2009 18:38:20 +0200 Dominick Grift wrote: > On Fri, Sep 25, 2009 at 03:35:52PM +0000, tarnait wrote: > > type=AVC msg=audit(1253870574.325:17): avc: denied { search } > > for pid=921 comm="pppd" name="root" dev=sda1 ino=12 > > scontext=system_u:system_r:pppd_t:s0 > > tcontext=unconfined_u:object_r:unconfined_home_dir_t:s0 tclass=dir > > Was caused by: Missing type enforcement (TE) allow rule. > > > > You can use audit2allow to generate a loadable > > module to allow this access. > > > > This also *may* be a labelling issue. pppd wants to search /root > dir. /root dir has type unconfined_home_dir_t. see if this is > correct: matchpathcon /root restorecon -R /root > > /root usually has type admin_home_t and i do not see any good reason > why pppd should be able to search it. misconfiguration/misusage maybe? pppd looks for ~/.ppprc, so if you're using it as root (e.g. to connect to your ISP) you're going to see this. Haven't found any way of turning it off either. Paul. From tarnai_t at yahoo.de Sat Sep 26 09:56:01 2009 From: tarnai_t at yahoo.de (tarnait) Date: Sat, 26 Sep 2009 09:56:01 +0000 (GMT) Subject: AW: Dear List members In-Reply-To: <20090926011058.3b85d5d5@metropolis.intra.city-fan.org> References: <708302.79400.qm@web24104.mail.ird.yahoo.com> <20090925163818.GA14076@notebook3.grift.internal> <20090926011058.3b85d5d5@metropolis.intra.city-fan.org> Message-ID: <586576.55669.qm@web24103.mail.ird.yahoo.com> Hi, yeah the console problem was that I use static udev, and the underlying /dev/console didn't have the proper label. Now I'm down to two problems: #============= iptables_t ============== allow iptables_t pppd_t:packet_socket { read write }; #============= pppd_t ============== allow pppd_t unconfined_home_dir_t:dir search; as I use iptables to redirect traffic from wlan0 to ppp0 I assue it's safe to add them. Thanks for your help, Kindest Regards ________________________________ Von: Paul Howarth An: Dominick Grift CC: fedora-selinux-list at redhat.com Gesendet: Samstag, den 26. September 2009, 02:10:58 Uhr Betreff: Re: Dear List members On Fri, 25 Sep 2009 18:38:20 +0200 Dominick Grift wrote: > On Fri, Sep 25, 2009 at 03:35:52PM +0000, tarnait wrote: > > type=AVC msg=audit(1253870574.325:17): avc: denied { search } > > for pid=921 comm="pppd" name="root" dev=sda1 ino=12 > > scontext=system_u:system_r:pppd_t:s0 > > tcontext=unconfined_u:object_r:unconfined_home_dir_t:s0 tclass=dir > > Was caused by: Missing type enforcement (TE) allow rule. > > > > You can use audit2allow to generate a loadable > > module to allow this access. > > > > This also *may* be a labelling issue. pppd wants to search /root > dir. /root dir has type unconfined_home_dir_t. see if this is > correct: matchpathcon /root restorecon -R /root > > /root usually has type admin_home_t and i do not see any good reason > why pppd should be able to search it. misconfiguration/misusage maybe? pppd looks for ~/.ppprc, so if you're using it as root (e.g. to connect to your ISP) you're going to see this. Haven't found any way of turning it off either. Paul. -- fedora-selinux-list mailing list fedora-selinux-list at redhat.com https://www.redhat.com/mailman/listinfo/fedora-selinux-list -------------- next part -------------- An HTML attachment was scrubbed... URL: From myrobmail at gmail.com Sat Sep 26 15:15:36 2009 From: myrobmail at gmail.com (Roberto Sassu) Date: Sat, 26 Sep 2009 17:15:36 +0200 Subject: Custom labeling network interfaces Message-ID: <200909261715.36658.myrobmail@gmail.com> Hi all i want to create a set of rules that allow the administrator to decide the network interfaces on which daemons can listen to. To do this i created a custom policy module to define the type eth0_netif_t which is bound to the eth0 interface. type eth0_netif_t, netif_type; typeattribute eth0_netif_t netif_type; ifdef(`enable_mls',` gen_require(`type unlabeled_t;') netifcon eth0 gen_context(system_u:object_r:eth0_netif_t,s0 - mls_systemhigh) gen_context(system_u:object_r:unlabeled_t,s0 - mls_systemhigh) ') Next, i executed the following command: semanage interface -a -t eth0_netif_t eth0 Then, without adding extra rules i tried to start the sshd daemon on this interface and the operation was successful. I see with the apol utility that sshd is allowed to bind on the generic interface netif_t but not on eth0_netif_t. How it's possible to explicitly grant the permission to listen on eth0 for each daemon which needs it? Thanks in advance for replies. From domg472 at gmail.com Sat Sep 26 16:29:48 2009 From: domg472 at gmail.com (Dominick Grift) Date: Sat, 26 Sep 2009 18:29:48 +0200 Subject: Custom labeling network interfaces In-Reply-To: <200909261715.36658.myrobmail@gmail.com> References: <200909261715.36658.myrobmail@gmail.com> Message-ID: <20090926162947.GA3747@notebook3.grift.internal> On Sat, Sep 26, 2009 at 05:15:36PM +0200, Roberto Sassu wrote: > Hi all > > i want to create a set of rules that allow the administrator to decide the > network interfaces on which daemons can listen to. > > To do this i created a custom policy module to define the type eth0_netif_t > which is bound to the eth0 interface. > > type eth0_netif_t, netif_type; > typeattribute eth0_netif_t netif_type; > > > ifdef(`enable_mls',` > > gen_require(`type unlabeled_t;') > netifcon eth0 gen_context(system_u:object_r:eth0_netif_t,s0 - mls_systemhigh) > gen_context(system_u:object_r:unlabeled_t,s0 - mls_systemhigh) > > ') > > Next, i executed the following command: > > semanage interface -a -t eth0_netif_t eth0 > > Then, without adding extra rules i tried to start the sshd daemon on this > interface and the operation was successful. I see with the apol utility that > sshd is allowed to bind on the generic interface netif_t but not on > eth0_netif_t. > > How it's possible to explicitly grant the permission to listen on eth0 for > each daemon which needs it? These types are declared in the corenetwork source policy, which is compiled into the base module. For you to be able to implement policy with regard to how domains can interact with network interface object type you would have to edit the policy. For example: This is from apache.te: corenet_tcp_sendrecv_all_if(httpd_t) corenet_udp_sendrecv_all_if(httpd_t) Which means that httpd_t can send and receive tcp and udp packets using all network interfaces. So these rule would have to be removed/replaced by rules that explicitly define how and which network interfaces httpd_t can access. This would have to be done for each domain that has access to network interfaces via the "all_if" interfaces. So if you really want to make this work, you should download the selinux-policy.src.rpm corresponding to the selinux-policy version that you currently have installed. Then extract the source rpm and prep the source ( apply the included patch(es) to the extracted included serefpolicy.tgz. Then you would have to declare your custom interface object type in corenetwork.te.in and remove the "all_if" interface calls from each module that calls it. Replace it with rules the you want to enforce. When you build the policy interfaces will be automatically created by the corenetwork module. You can call these interfaces instead of using "local policy" After you have modified the policy you would "clean the source" and repackage it (serefpolicy.tgz). Since you have already applies any included patches by redhat when you have "preparated the source" you no longer have to patch the source, thus you can remove any lines where it refers to 'patch' from the selinux-policy.spec that is included with the source rpm. Also "bump" the version in the spec file so that it can be installed without forcing installation. Then you would simply rebuild the selinux-policy.src.rpm using rpm-devtools (rpmbuild -ba selinux-policy.spec), and update your policy with rpm -Uvh selinux-policy*.rpm The problem with this method though is that from that point you are the maintainer of your implemented policy, meaning you can no longer blindly update from the redhat packages if you do not want your modification to be resetted. With EL5 this is not such a big problem since EL5 selinux-policy does not get updated very often. hth > > Thanks in advance for replies. > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From shintaro.fujiwara at gmail.com Sun Sep 27 03:18:51 2009 From: shintaro.fujiwara at gmail.com (Shintaro Fujiwara) Date: Sun, 27 Sep 2009 12:18:51 +0900 Subject: sesearch --neverallow is broken ? Message-ID: I typed in F11, sesearch --neverallow but seems it returns allow sentences. -- http://intrajp.no-ip.com/ Home Page From olivares14031 at yahoo.com Sun Sep 27 18:21:18 2009 From: olivares14031 at yahoo.com (Antonio Olivares) Date: Sun, 27 Sep 2009 11:21:18 -0700 (PDT) Subject: have finally succeeded installing rawhide by livecd, got sealert but couldn't load it :( Message-ID: <604745.63142.qm@web52612.mail.re2.yahoo.com> [liveuser at localhost ~]$ sealert Traceback (most recent call last): File "/usr/bin/sealert", line 37, in import slip.dbus.service File "/usr/lib/python2.6/site-packages/slip/dbus/__init__.py", line 1, in import bus ImportError: No module named bus [liveuser at localhost ~]$ dmesg | grep 'avc' type=1400 audit(1254092543.093:7): avc: denied { read } for pid=844 comm="passwd" path="/dev/console" dev=tmpfs ino=2114 scontext=system_u:system_r:passwd_t:s0 tcontext=system_u:object_r:console_device_t:s0 tclass=chr_file type=1400 audit(1254092543.094:8): avc: denied { read } for pid=844 comm="passwd" path="/dev/console" dev=tmpfs ino=2114 scontext=system_u:system_r:passwd_t:s0 tcontext=system_u:object_r:console_device_t:s0 tclass=chr_file installed from KDE-x86_64-20090926.19 [liveuser at localhost ~]$ uname -r 2.6.31.1-48.fc12.x86_64 [liveuser at localhost ~]$ cat /etc/fedora-release Fedora release 11.91 (Rawhide) Regards, Antonio From zbynek.houska at gmail.com Sun Sep 27 18:25:05 2009 From: zbynek.houska at gmail.com (Zbynek Houska) Date: Sun, 27 Sep 2009 19:25:05 +0100 Subject: Final year project ideas Message-ID: <761f67170909271125t493e9e2dx96158194dbd2f279@mail.gmail.com> All, I'm about to embark on a SELinux related final year project for BSc (Hons) in IT this semester. My goal is to learn SELinux well, compare to other (Linux) security projects, demystify it / demonstrate its pros and cons... I would like to do a thorough research on exploit / attack mitigation with SELinux as per Tresys website (http://www.tresys.com/innovation.php) and write a few (new) policies for software of my choice. I intend to use honeypots running Fedora 11 as my base system. However, I'm not sure if college class B network will produce conclusive results. Thus, I would appreciate support, guidance and comments from (seasoned) SELinux gurus, developers and practitioners on this list in order to point me in the right direction when it comes to sourcing literature, white papers, research work other people might already have conducted and overcoming pitfalls related to such testing environments. Kind regards, Zbynek -------------- next part -------------- An HTML attachment was scrubbed... URL: From justinmattock at gmail.com Sun Sep 27 19:01:31 2009 From: justinmattock at gmail.com (Justin P. Mattock) Date: Sun, 27 Sep 2009 12:01:31 -0700 Subject: have finally succeeded installing rawhide by livecd, got sealert but couldn't load it :( In-Reply-To: <604745.63142.qm@web52612.mail.re2.yahoo.com> References: <604745.63142.qm@web52612.mail.re2.yahoo.com> Message-ID: <4ABFB68B.80801@gmail.com> Antonio Olivares wrote: > [liveuser at localhost ~]$ sealert > Traceback (most recent call last): > File "/usr/bin/sealert", line 37, in > import slip.dbus.service > File "/usr/lib/python2.6/site-packages/slip/dbus/__init__.py", line 1, in > import bus > ImportError: No module named bus > [liveuser at localhost ~]$ dmesg | grep 'avc' > type=1400 audit(1254092543.093:7): avc: denied { read } for pid=844 comm="passwd" path="/dev/console" dev=tmpfs ino=2114 scontext=system_u:system_r:passwd_t:s0 tcontext=system_u:object_r:console_device_t:s0 tclass=chr_file > type=1400 audit(1254092543.094:8): avc: denied { read } for pid=844 comm="passwd" path="/dev/console" dev=tmpfs ino=2114 scontext=system_u:system_r:passwd_t:s0 tcontext=system_u:object_r:console_device_t:s0 tclass=chr_file > > installed from KDE-x86_64-20090926.19 > > [liveuser at localhost ~]$ uname -r > 2.6.31.1-48.fc12.x86_64 > [liveuser at localhost ~]$ cat /etc/fedora-release > Fedora release 11.91 (Rawhide) > > > Regards, > > Antonio > > > > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list > > your missing a dbus module I think it might be in the python-dbus package. Justin P. Mattock From domg472 at gmail.com Sun Sep 27 20:53:29 2009 From: domg472 at gmail.com (Dominick Grift) Date: Sun, 27 Sep 2009 22:53:29 +0200 Subject: Final year project ideas In-Reply-To: <761f67170909271125t493e9e2dx96158194dbd2f279@mail.gmail.com> References: <761f67170909271125t493e9e2dx96158194dbd2f279@mail.gmail.com> Message-ID: <20090927205327.GB7217@notebook3.grift.internal> On Sun, Sep 27, 2009 at 07:25:05PM +0100, Zbynek Houska wrote: > All, > > I'm about to embark on a SELinux related final year project for BSc (Hons) > in IT this semester. My goal is to learn SELinux well, compare to other > (Linux) security projects, demystify it / demonstrate its pros and cons... > I would like to do a thorough research on exploit / attack mitigation with > SELinux as per Tresys website (http://www.tresys.com/innovation.php) and > write a few (new) policies for software of my choice. I intend to use > honeypots running Fedora 11 as my base system. However, I'm not sure if > college class B network will produce conclusive results. > > Thus, I would appreciate support, guidance and comments from (seasoned) > SELinux gurus, developers and practitioners on this list in order to point > me in the right direction when it comes to sourcing literature, white > papers, research work other people might already have conducted and > overcoming pitfalls related to such testing environments. Hello, Here is a list with links to SELinux resources. http://selinuxproject.org/page/User_Resources You have already found the right mailing lists (except Tresys refpolicy list). I Recommend that you also bookmark and study the list Archives: https://www.redhat.com/archives/fedora-selinux-list/ http://oss.tresys.com/pipermail/refpolicy/ http://marc.info/?l=selinux&r=1&w=2 Also have a look at this presentation: http://people.redhat.com/dwalsh/SELinux/Presentations/ManageRHEL5.pdf This book: http://www.selinuxbyexample.com/ These: http://docs.fedoraproject.org/selinux-user-guide/f11/en-US/ http://docs.fedoraproject.org/selinux-managing-confined-services-guide/en-US/F11/html/ And this: http://www.nsa.gov/research/selinux/ hth > > Kind regards, > > Zbynek > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From chenhuan126 at 126.com Mon Sep 28 01:50:12 2009 From: chenhuan126 at 126.com (chenh) Date: Mon, 28 Sep 2009 09:50:12 +0800 (CST) Subject: Can I allow console_type_t to access pppd_t? Message-ID: <10547869.697791254102612911.JavaMail.coremail@bj126app25.126.com> Everytime I use adsl connection, AVC alerts: "SELinux is preventing consoletype (consoletype_t) "read write" pppd_t. " I typed "audit2allow -a" and saw: #============= alsa_t ============== allow alsa_t file_t:file read; #============= consoletype_t ============== allow consoletype_t file_t:file read; allow consoletype_t pppd_t:packet_socket { read write }; #============= dmesg_t ============== allow dmesg_t file_t:file read; #============= hwclock_t ============== allow hwclock_t file_t:file read; #============= ifconfig_t ============== allow ifconfig_t file_t:file read; #============= mount_t ============== allow mount_t file_t:file unlink; #============= setroubleshootd_t ============== allow setroubleshootd_t locate_var_lib_t:file read; There're two rule about consoletype above. Is it safe to add them using audit2allow? Thanks! -------------- next part -------------- An HTML attachment was scrubbed... URL: From russell at coker.com.au Mon Sep 28 01:23:20 2009 From: russell at coker.com.au (Russell Coker) Date: Mon, 28 Sep 2009 11:23:20 +1000 Subject: Final year project ideas In-Reply-To: <761f67170909271125t493e9e2dx96158194dbd2f279@mail.gmail.com> References: <761f67170909271125t493e9e2dx96158194dbd2f279@mail.gmail.com> Message-ID: <200909281123.22364.russell@coker.com.au> On Mon, 28 Sep 2009, Zbynek Houska wrote: > write a few (new) policies for software of my choice. ?I intend to use > honeypots running Fedora 11 as my base system. However, I'm not sure if > college class B network will produce conclusive results. > > Thus, I would appreciate support, guidance and comments from (seasoned) > SELinux gurus, developers and practitioners on this list in order to point > me in the right direction when it comes to sourcing literature, white > papers, research work other people might already have conducted and > overcoming pitfalls related to such testing environments. Firstly firewall all traffic from the system in question - other than that which is required for it to be vulnerable to the attacks you desire. If you allow ICMP echo access then someone will try and ping-flood other systems. If you allow outbound TCP connections then your system may be used to compromise others. Probably the best way to run honeypots is to use Xen or KVM to run virtual machines. This means that you have lots of good options for monitoring the machines while they are attacked. But don't assume that Xvn or KVM is flawless - IE don't have any sensitive data on the same physical machine. The purpose of a honeypot is to attract attack, running the latest versions of software is going to make it more difficult for attackers and partially defeats this goal. Maybe running Fedora 10 (or earlier) with no updates would be a better option. Of course you will probably want to back-port the latest SE Linux policy before you do this (which shouldn't be difficult). It's been a while since anyone ran a SE Linux Play Machine on Fedora, I would be happy to offer detailed advice and some testing if you want to run one. -- russell at coker.com.au http://etbe.coker.com.au/ My Main Blog http://doc.coker.com.au/ My Documents Blog From roberto.sassu at polito.it Mon Sep 28 13:06:48 2009 From: roberto.sassu at polito.it (Roberto Sassu) Date: Mon, 28 Sep 2009 15:06:48 +0200 Subject: Custom labeling network interfaces In-Reply-To: <20090926162947.GA3747@notebook3.grift.internal> References: <200909261715.36658.myrobmail@gmail.com> <20090926162947.GA3747@notebook3.grift.internal> Message-ID: <200909281506.48954.roberto.sassu@polito.it> I downloaded the source policy and i created this patch: ---------------- --- serefpolicy-3.6.12/policy/modules/kernel/corenetwork.te.in.old 2009-09-28 12:09:24.617041763 +0200 +++ serefpolicy-3.6.12/policy/modules/kernel/corenetwork.te.in 2009-09-28 12:09:51.410362006 +0200 @@ -261,6 +261,11 @@ network_interface(lo, lo,s0 - mls_system typealias netif_t alias { lo_netif_t netif_lo_t }; ') +build_option(`enable_mls',` +network_interface(eth0, eth0,s0 - mls_systemhigh) +') + + ######################################## # # Unconfined access to this module ----------------- Then i recompiled the whole policy using the spec file, i installed it and i relabeled the entire file system. The problem is that i'm not able to use the new interfaces, for example "corenet_tcp_sendrecv_eth0_if". When building a custom module that calls it, the following message appears: ----------------- Compiling targeted userdom module /usr/bin/checkmodule: loading policy configuration from tmp/userdom.tmp userdom.te":64:ERROR 'syntax error' at token 'corenet_tcp_sendrecv_eth0_if' on line 151624: corenet_tcp_sendrecv_eth0_if(sshdlow_t) #line 64 /usr/bin/checkmodule: error(s) encountered while parsing configuration make: *** [tmp/userdom.mod] Error 1 ----------------- In the patch described above i miss the line typealias netif.... because i suppose that if eth0_netif_t is an alias of netif_t, allowing an access rule for the last type means granting the privilege for all interfaces. Lastly i have another question about the ssh server and its ability to set new domains for processes of remote users. I want to have two different servers, one which is able to set all possible domains for the shell, another which have a capability to set only a subset of domain. To accomplish this task i used the interface "ssh_server_template", i copied from the file ssh.te all rules that involve the domain sshd_t and i added the following lines: ------------------- interface(`ssh_server_users_interaction',` gen_require(` type $1_t, shell_exec_t; type $2; ') allow $1_t $2: process transition; allow $2 $1_t:process sigchld; allow $1_t $2:process { siginh }; dontaudit $1_t $2:process { noatsecure }; ') ------------------- Is this correct or there's a way for that to be circumvented? Thanks for replies. On Saturday 26 September 2009 18:29:48 Dominick Grift wrote: > On Sat, Sep 26, 2009 at 05:15:36PM +0200, Roberto Sassu wrote: > > Hi all > > > > i want to create a set of rules that allow the administrator to decide > > the network interfaces on which daemons can listen to. > > > > To do this i created a custom policy module to define the type > > eth0_netif_t which is bound to the eth0 interface. > > > > type eth0_netif_t, netif_type; > > typeattribute eth0_netif_t netif_type; > > > > > > ifdef(`enable_mls',` > > > > gen_require(`type unlabeled_t;') > > netifcon eth0 gen_context(system_u:object_r:eth0_netif_t,s0 - > > mls_systemhigh) gen_context(system_u:object_r:unlabeled_t,s0 - > > mls_systemhigh) > > > > ') > > > > Next, i executed the following command: > > > > semanage interface -a -t eth0_netif_t eth0 > > > > Then, without adding extra rules i tried to start the sshd daemon on this > > interface and the operation was successful. I see with the apol utility > > that sshd is allowed to bind on the generic interface netif_t but not on > > eth0_netif_t. > > > > How it's possible to explicitly grant the permission to listen on eth0 > > for each daemon which needs it? > > These types are declared in the corenetwork source policy, which is > compiled into the base module. For you to be able to implement policy with > regard to how domains can interact with network interface object type you > would have to edit the policy. For example: > > This is from apache.te: > > corenet_tcp_sendrecv_all_if(httpd_t) > corenet_udp_sendrecv_all_if(httpd_t) > > Which means that httpd_t can send and receive tcp and udp packets using all > network interfaces. So these rule would have to be removed/replaced by > rules that explicitly define how and which network interfaces httpd_t can > access. > > This would have to be done for each domain that has access to network > interfaces via the "all_if" interfaces. > > So if you really want to make this work, you should download the > selinux-policy.src.rpm corresponding to the selinux-policy version that > you currently have installed. Then extract the source rpm and prep the > source ( apply the included patch(es) to the extracted included > serefpolicy.tgz. > > Then you would have to declare your custom interface object type in > corenetwork.te.in and remove the "all_if" interface calls from each module > that calls it. Replace it with rules the you want to enforce. When you > build the policy interfaces will be automatically created by the > corenetwork module. You can call these interfaces instead of using "local > policy" > > After you have modified the policy you would "clean the source" and > repackage it (serefpolicy.tgz). Since you have already applies any > included patches by redhat when you have "preparated the source" you no > longer have to patch the source, thus you can remove any lines where it > refers to 'patch' from the selinux-policy.spec that is included with the > source rpm. > > Also "bump" the version in the spec file so that it can be installed > without forcing installation. > > Then you would simply rebuild the selinux-policy.src.rpm using rpm-devtools > (rpmbuild -ba selinux-policy.spec), and update your policy with rpm -Uvh > selinux-policy*.rpm > > The problem with this method though is that from that point you are the > maintainer of your implemented policy, meaning you can no longer blindly > update from the redhat packages if you do not want your modification to be > resetted. > > With EL5 this is not such a big problem since EL5 selinux-policy does not > get updated very often. > > hth > > > Thanks in advance for replies. > > > > -- > > fedora-selinux-list mailing list > > fedora-selinux-list at redhat.com > > https://www.redhat.com/mailman/listinfo/fedora-selinux-list > From domg472 at gmail.com Mon Sep 28 13:38:23 2009 From: domg472 at gmail.com (Dominick Grift) Date: Mon, 28 Sep 2009 15:38:23 +0200 Subject: Custom labeling network interfaces In-Reply-To: <200909281506.48954.roberto.sassu@polito.it> References: <200909261715.36658.myrobmail@gmail.com> <20090926162947.GA3747@notebook3.grift.internal> <200909281506.48954.roberto.sassu@polito.it> Message-ID: <20090928133822.GA10400@notebook3.grift.internal> On Mon, Sep 28, 2009 at 03:06:48PM +0200, Roberto Sassu wrote: > I downloaded the source policy and i created this patch: > ---------------- > --- serefpolicy-3.6.12/policy/modules/kernel/corenetwork.te.in.old > 2009-09-28 12:09:24.617041763 +0200 > +++ serefpolicy-3.6.12/policy/modules/kernel/corenetwork.te.in 2009-09-28 > 12:09:51.410362006 +0200 > @@ -261,6 +261,11 @@ network_interface(lo, lo,s0 - mls_system > typealias netif_t alias { lo_netif_t netif_lo_t }; > ') > > +build_option(`enable_mls',` > +network_interface(eth0, eth0,s0 - mls_systemhigh) > +') > + > + > ######################################## > # > # Unconfined access to this module > ----------------- > > > Then i recompiled the whole policy using the spec file, i installed it and i > relabeled the entire file system. > The problem is that i'm not able to use the new interfaces, for example > "corenet_tcp_sendrecv_eth0_if". When building a custom module that calls it, > the following message appears: > > ----------------- > Compiling targeted userdom module > /usr/bin/checkmodule: loading policy configuration from tmp/userdom.tmp > userdom.te":64:ERROR 'syntax error' at token 'corenet_tcp_sendrecv_eth0_if' on > line 151624: > corenet_tcp_sendrecv_eth0_if(sshdlow_t) > #line 64 > /usr/bin/checkmodule: error(s) encountered while parsing configuration > make: *** [tmp/userdom.mod] Error 1 > ----------------- > > In the patch described above i miss the line typealias netif.... because i > suppose that if eth0_netif_t is an alias of netif_t, allowing an access rule > for the last type means granting the privilege for all interfaces. I think your declaration is wrong: Try this instead: type netif_eth0_t, netif_type; sid netif gen_context(system_u:object_r:netif_eth0_t,s0 - mls_systemhigh) The syntax error signals that you interface call does not exists corenet_tcp_sendrecv_eth0_if That would make sense, since the declaration was wrong (non existant) .. Although i am not sure, it has been a long time since i tried it. > > Lastly i have another question about the ssh server and its ability to set new > domains for processes of remote users. > I want to have two different servers, one which is able to set all possible > domains for the shell, another which have a capability to set only a subset of > domain. To accomplish this task i used the interface "ssh_server_template", i > copied from the file ssh.te all rules that involve the domain sshd_t and i > added the following lines: > > ------------------- > interface(`ssh_server_users_interaction',` > gen_require(` > type $1_t, shell_exec_t; > type $2; > ') > > allow $1_t $2: process transition; > allow $2 $1_t:process sigchld; > allow $1_t $2:process { siginh }; > dontaudit $1_t $2:process { noatsecure }; > ') > ------------------- > > Is this correct or there's a way for that to be circumvented? > Thanks for replies. Not sure about this one. sorry. Did you test it? > > > > On Saturday 26 September 2009 18:29:48 Dominick Grift wrote: > > On Sat, Sep 26, 2009 at 05:15:36PM +0200, Roberto Sassu wrote: > > > Hi all > > > > > > i want to create a set of rules that allow the administrator to decide > > > the network interfaces on which daemons can listen to. > > > > > > To do this i created a custom policy module to define the type > > > eth0_netif_t which is bound to the eth0 interface. > > > > > > type eth0_netif_t, netif_type; > > > typeattribute eth0_netif_t netif_type; > > > > > > > > > ifdef(`enable_mls',` > > > > > > gen_require(`type unlabeled_t;') > > > netifcon eth0 gen_context(system_u:object_r:eth0_netif_t,s0 - > > > mls_systemhigh) gen_context(system_u:object_r:unlabeled_t,s0 - > > > mls_systemhigh) > > > > > > ') > > > > > > Next, i executed the following command: > > > > > > semanage interface -a -t eth0_netif_t eth0 > > > > > > Then, without adding extra rules i tried to start the sshd daemon on this > > > interface and the operation was successful. I see with the apol utility > > > that sshd is allowed to bind on the generic interface netif_t but not on > > > eth0_netif_t. > > > > > > How it's possible to explicitly grant the permission to listen on eth0 > > > for each daemon which needs it? > > > > These types are declared in the corenetwork source policy, which is > > compiled into the base module. For you to be able to implement policy with > > regard to how domains can interact with network interface object type you > > would have to edit the policy. For example: > > > > This is from apache.te: > > > > corenet_tcp_sendrecv_all_if(httpd_t) > > corenet_udp_sendrecv_all_if(httpd_t) > > > > Which means that httpd_t can send and receive tcp and udp packets using all > > network interfaces. So these rule would have to be removed/replaced by > > rules that explicitly define how and which network interfaces httpd_t can > > access. > > > > This would have to be done for each domain that has access to network > > interfaces via the "all_if" interfaces. > > > > So if you really want to make this work, you should download the > > selinux-policy.src.rpm corresponding to the selinux-policy version that > > you currently have installed. Then extract the source rpm and prep the > > source ( apply the included patch(es) to the extracted included > > serefpolicy.tgz. > > > > Then you would have to declare your custom interface object type in > > corenetwork.te.in and remove the "all_if" interface calls from each module > > that calls it. Replace it with rules the you want to enforce. When you > > build the policy interfaces will be automatically created by the > > corenetwork module. You can call these interfaces instead of using "local > > policy" > > > > After you have modified the policy you would "clean the source" and > > repackage it (serefpolicy.tgz). Since you have already applies any > > included patches by redhat when you have "preparated the source" you no > > longer have to patch the source, thus you can remove any lines where it > > refers to 'patch' from the selinux-policy.spec that is included with the > > source rpm. > > > > Also "bump" the version in the spec file so that it can be installed > > without forcing installation. > > > > Then you would simply rebuild the selinux-policy.src.rpm using rpm-devtools > > (rpmbuild -ba selinux-policy.spec), and update your policy with rpm -Uvh > > selinux-policy*.rpm > > > > The problem with this method though is that from that point you are the > > maintainer of your implemented policy, meaning you can no longer blindly > > update from the redhat packages if you do not want your modification to be > > resetted. > > > > With EL5 this is not such a big problem since EL5 selinux-policy does not > > get updated very often. > > > > hth > > > > > Thanks in advance for replies. > > > > > > -- > > > fedora-selinux-list mailing list > > > fedora-selinux-list at redhat.com > > > https://www.redhat.com/mailman/listinfo/fedora-selinux-list > > > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From domg472 at gmail.com Mon Sep 28 13:44:37 2009 From: domg472 at gmail.com (Dominick Grift) Date: Mon, 28 Sep 2009 15:44:37 +0200 Subject: Custom labeling network interfaces In-Reply-To: <200909281506.48954.roberto.sassu@polito.it> References: <200909261715.36658.myrobmail@gmail.com> <20090926162947.GA3747@notebook3.grift.internal> <200909281506.48954.roberto.sassu@polito.it> Message-ID: <20090928134436.GB10400@notebook3.grift.internal> On Mon, Sep 28, 2009 at 03:06:48PM +0200, Roberto Sassu wrote: > I downloaded the source policy and i created this patch: > ---------------- > --- serefpolicy-3.6.12/policy/modules/kernel/corenetwork.te.in.old > 2009-09-28 12:09:24.617041763 +0200 > +++ serefpolicy-3.6.12/policy/modules/kernel/corenetwork.te.in 2009-09-28 > 12:09:51.410362006 +0200 > @@ -261,6 +261,11 @@ network_interface(lo, lo,s0 - mls_system > typealias netif_t alias { lo_netif_t netif_lo_t }; > ') > > +build_option(`enable_mls',` > +network_interface(eth0, eth0,s0 - mls_systemhigh) > +') .. Or maybe this is correct except for it being in the mls block. Not sure if you build policy with type=mls > + > + > ######################################## > # > # Unconfined access to this module > ----------------- > > > Then i recompiled the whole policy using the spec file, i installed it and i > relabeled the entire file system. > The problem is that i'm not able to use the new interfaces, for example > "corenet_tcp_sendrecv_eth0_if". When building a custom module that calls it, > the following message appears: > > ----------------- > Compiling targeted userdom module > /usr/bin/checkmodule: loading policy configuration from tmp/userdom.tmp > userdom.te":64:ERROR 'syntax error' at token 'corenet_tcp_sendrecv_eth0_if' on > line 151624: > corenet_tcp_sendrecv_eth0_if(sshdlow_t) > #line 64 > /usr/bin/checkmodule: error(s) encountered while parsing configuration > make: *** [tmp/userdom.mod] Error 1 > ----------------- > > In the patch described above i miss the line typealias netif.... because i > suppose that if eth0_netif_t is an alias of netif_t, allowing an access rule > for the last type means granting the privilege for all interfaces. > > Lastly i have another question about the ssh server and its ability to set new > domains for processes of remote users. > I want to have two different servers, one which is able to set all possible > domains for the shell, another which have a capability to set only a subset of > domain. To accomplish this task i used the interface "ssh_server_template", i > copied from the file ssh.te all rules that involve the domain sshd_t and i > added the following lines: > > ------------------- > interface(`ssh_server_users_interaction',` > gen_require(` > type $1_t, shell_exec_t; > type $2; > ') > > allow $1_t $2: process transition; > allow $2 $1_t:process sigchld; > allow $1_t $2:process { siginh }; > dontaudit $1_t $2:process { noatsecure }; > ') > ------------------- > > Is this correct or there's a way for that to be circumvented? > Thanks for replies. > > > > On Saturday 26 September 2009 18:29:48 Dominick Grift wrote: > > On Sat, Sep 26, 2009 at 05:15:36PM +0200, Roberto Sassu wrote: > > > Hi all > > > > > > i want to create a set of rules that allow the administrator to decide > > > the network interfaces on which daemons can listen to. > > > > > > To do this i created a custom policy module to define the type > > > eth0_netif_t which is bound to the eth0 interface. > > > > > > type eth0_netif_t, netif_type; > > > typeattribute eth0_netif_t netif_type; > > > > > > > > > ifdef(`enable_mls',` > > > > > > gen_require(`type unlabeled_t;') > > > netifcon eth0 gen_context(system_u:object_r:eth0_netif_t,s0 - > > > mls_systemhigh) gen_context(system_u:object_r:unlabeled_t,s0 - > > > mls_systemhigh) > > > > > > ') > > > > > > Next, i executed the following command: > > > > > > semanage interface -a -t eth0_netif_t eth0 > > > > > > Then, without adding extra rules i tried to start the sshd daemon on this > > > interface and the operation was successful. I see with the apol utility > > > that sshd is allowed to bind on the generic interface netif_t but not on > > > eth0_netif_t. > > > > > > How it's possible to explicitly grant the permission to listen on eth0 > > > for each daemon which needs it? > > > > These types are declared in the corenetwork source policy, which is > > compiled into the base module. For you to be able to implement policy with > > regard to how domains can interact with network interface object type you > > would have to edit the policy. For example: > > > > This is from apache.te: > > > > corenet_tcp_sendrecv_all_if(httpd_t) > > corenet_udp_sendrecv_all_if(httpd_t) > > > > Which means that httpd_t can send and receive tcp and udp packets using all > > network interfaces. So these rule would have to be removed/replaced by > > rules that explicitly define how and which network interfaces httpd_t can > > access. > > > > This would have to be done for each domain that has access to network > > interfaces via the "all_if" interfaces. > > > > So if you really want to make this work, you should download the > > selinux-policy.src.rpm corresponding to the selinux-policy version that > > you currently have installed. Then extract the source rpm and prep the > > source ( apply the included patch(es) to the extracted included > > serefpolicy.tgz. > > > > Then you would have to declare your custom interface object type in > > corenetwork.te.in and remove the "all_if" interface calls from each module > > that calls it. Replace it with rules the you want to enforce. When you > > build the policy interfaces will be automatically created by the > > corenetwork module. You can call these interfaces instead of using "local > > policy" > > > > After you have modified the policy you would "clean the source" and > > repackage it (serefpolicy.tgz). Since you have already applies any > > included patches by redhat when you have "preparated the source" you no > > longer have to patch the source, thus you can remove any lines where it > > refers to 'patch' from the selinux-policy.spec that is included with the > > source rpm. > > > > Also "bump" the version in the spec file so that it can be installed > > without forcing installation. > > > > Then you would simply rebuild the selinux-policy.src.rpm using rpm-devtools > > (rpmbuild -ba selinux-policy.spec), and update your policy with rpm -Uvh > > selinux-policy*.rpm > > > > The problem with this method though is that from that point you are the > > maintainer of your implemented policy, meaning you can no longer blindly > > update from the redhat packages if you do not want your modification to be > > resetted. > > > > With EL5 this is not such a big problem since EL5 selinux-policy does not > > get updated very often. > > > > hth > > > > > Thanks in advance for replies. > > > > > > -- > > > fedora-selinux-list mailing list > > > fedora-selinux-list at redhat.com > > > https://www.redhat.com/mailman/listinfo/fedora-selinux-list > > > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From d.rye at roadtech.co.uk Mon Sep 28 15:22:18 2009 From: d.rye at roadtech.co.uk (J. David Rye of Roadtech) Date: Mon, 28 Sep 2009 16:22:18 +0100 Subject: Clamav/SeLinux, issue with system call recvmsg, and auxilary data. Message-ID: <200909281622.19118.d.rye@roadtech.co.uk> Hello All I triggered this issue with clamav/clamav-milter 0.95.2 from rpmforge running on a test box with Centos 5.3 Clamd opens a socket /var/run/clamav/clamd.sock to accept requests to scan things. ls -Z /var/run/clamav/clamd.sock srwxrwxrwx clamav clamav root:object_r:clamd_var_run_t /var/run/clamav/clamd.sock Requests are read using the system call recvmsg, this allows for the passing auxiliary control data. Clamav-milter 0.95.2 uses this to pass a handle to the temp file containing the data to be scanned With SeLinux set to targeted enforcing, this call reads and returns the normal data fine, but returns with the flag MSG_CTRUNC set. according to the man page this is "indicates that some control data were discarded due to lack of space in the buffer for ancillary data." clamd responded by closing the socket, clamav-milter responded to the closed socket by looping a 100% CPU. :-( Running the audit log through audit2allow suggests grep clam /var/log/audit/audit.log | audit2allow -m local > local.te [root at fallback0 selinux]# cat local.te module local 1.0; require { type initrc_tmp_t; type proc_t; type sysctl_kernel_t; type clamd_t; class dir search; class file { read write getattr }; } #============= clamd_t ============== allow clamd_t initrc_tmp_t:file { read write getattr }; allow clamd_t proc_t:file { read getattr }; allow clamd_t sysctl_kernel_t:dir search; allow clamd_t sysctl_kernel_t:file read; The allow clamd_t proc_t:file { read getattr }; looks to relate to reading /proc/meminfo allow clamd_t sysctl_kernel_t:dir search; allow clamd_t sysctl_kernel_t:file read; Look to relate to these log entries type=AVC msg=audit(1254139856.343:48724): avc: denied { search } for pid=14771 comm="clamd" name="kernel" dev=proc ino=-268435416 scontext=root:system_r:clamd_t:s0 tcontext=system_u:object_r:sysctl_kernel_t:s0 tclass=dir type=AVC msg=audit(1254139856.343:48724): avc: denied { read } for pid=14771 comm="clamd" name="ngroups_max" dev=proc ino=-268435368 scontext=root:system_r:clamd_t:s0 tcontext=system_u:object_r:sysctl_kernel_t:s0 tclass=file type=AVC msg=audit(1254149740.665:48885): avc: denied { search } for pid=1261 comm="clamd" name="kernel" dev=proc ino=-268435416 scontext=root:system_r:clamd_t:s0 tcontext=system_u:object_r:sysctl_kernel_t:s0 tclass=dir This if I have figured it out right relate to something that clamd is calling in turn trying to read /proc/sys/kernel/ngroups_max So by elimination allow clamd_t initrc_tmp_t:file { read write getattr }; Must relate to the the use of auxiliary data with the socket, and the following log entries but I do not see why. Can anyone explain? type=AVC msg=audit(1254150147.188:48924): avc: denied { read write } for pid=1288 comm="clamd" path=2F746D702F636C616D61762D3063666237656532666331656139656636323364373463316236626532623735202864656C6574656429 dev=dm-0 ino=34668546 scontext=root:system_r:clamd_t:s0 tcontext=root:object_r:initrc_tmp_t:s0 tclass=file type=AVC msg=audit(1254150153.681:48925): avc: denied { read write } for pid=1288 comm="clamd" path=2F746D702F636C616D61762D3336316332323033323138613239633865363633633937303962663133363664202864656C6574656429 dev=dm-0 ino=34668546 scontext=root:system_r:clamd_t:s0 tcontext=root:object_r:initrc_tmp_t:s0 tclass=file type=AVC msg=audit(1254150177.903:48926): avc: denied { read write } for pid=1288 comm="clamd" path=2F746D702F636C616D61762D3366636162623138633237636231383466643064656630643838353063363933202864656C6574656429 dev=dm-0 ino=34668546 scontext=root:system_r:clamd_t:s0 tcontext=root:object_r:initrc_tmp_t:s0 tclass=file type=AVC msg=audit(1254150188.366:48927): avc: denied { read write } for pid=1288 comm="clamd" path=2F746D702F636C616D61762D6366393131623632353130333564353832656435396466663136373362626131202864656C6574656429 dev=dm-0 ino=34668546 scontext=root:system_r:clamd_t:s0 tcontext=root:object_r:initrc_tmp_t:s0 tclass=file type=AVC msg=audit(1254150220.428:48928): avc: denied { read write } for pid=1288 comm="clamd" path=2F746D702F636C616D61762D3931633534623761393630653531386630363539653033363537303937323135202864656C6574656429 dev=dm-0 ino=34668546 scontext=root:system_r:clamd_t:s0 tcontext=root:object_r:initrc_tmp_t:s0 tclass=file Yours J. David Rye ************************************************************************* This e-mail is confidential and may be legally privileged. It is intended solely for the use of the individual(s) to whom it is addressed. Any content in this message is not necessarily a view or statement from Road Tech Computer Systems Limited but is that of the individual sender. If you are not the intended recipient, be advised that you have received this e-mail in error and that any use, dissemination, forwarding, printing, or copying of this e-mail is strictly prohibited. We use reasonable endeavours to virus scan all e-mails leaving the company but no warranty is given that this e-mail and any attachments are virus free. You should undertake your own virus checking. The right to monitor e-mail communications through our networks is reserved by us Road Tech Computer Systems Ltd. Shenley Hall, Rectory Lane, Shenley, Radlett, Hertfordshire, WD7 9AN. - VAT Registration No GB 449 3582 17 Registered in England No: 02017435, Registered Address: Charter Court, Midland Road, Hemel Hempstead, Hertfordshire, HP2 5GE. ************************************************************************* From zbynek.houska at gmail.com Mon Sep 28 15:23:42 2009 From: zbynek.houska at gmail.com (Zbynek Houska) Date: Mon, 28 Sep 2009 16:23:42 +0100 Subject: Final year project ideas In-Reply-To: <20090927205327.GB7217@notebook3.grift.internal> References: <761f67170909271125t493e9e2dx96158194dbd2f279@mail.gmail.com> <20090927205327.GB7217@notebook3.grift.internal> Message-ID: <761f67170909280823l6df1ed2fj69af63d62f7f223d@mail.gmail.com> On Sun, Sep 27, 2009 at 9:53 PM, Dominick Grift wrote: > On Sun, Sep 27, 2009 at 07:25:05PM +0100, Zbynek Houska wrote: > > All, > > > > I'm about to embark on a SELinux related final year project for BSc > (Hons) > > in IT this semester. My goal is to learn SELinux well, compare to other > > (Linux) security projects, demystify it / demonstrate its pros and > cons... > > I would like to do a thorough research on exploit / attack mitigation > with > > SELinux as per Tresys website (http://www.tresys.com/innovation.php) and > > write a few (new) policies for software of my choice. I intend to use > > honeypots running Fedora 11 as my base system. However, I'm not sure if > > college class B network will produce conclusive results. > > > > Thus, I would appreciate support, guidance and comments from (seasoned) > > SELinux gurus, developers and practitioners on this list in order to > point > > me in the right direction when it comes to sourcing literature, white > > papers, research work other people might already have conducted and > > overcoming pitfalls related to such testing environments. > > Hello, > Hi Dominick, > > Here is a list with links to SELinux resources. > http://selinuxproject.org/page/User_Resources > > You have already found the right mailing lists (except Tresys refpolicy > list). I Recommend that you also bookmark and study the list Archives: > > https://www.redhat.com/archives/fedora-selinux-list/ > http://oss.tresys.com/pipermail/refpolicy/ > http://marc.info/?l=selinux&r=1&w=2 Oh, sure I always try to go through archives. > > > Also have a look at this presentation: > http://people.redhat.com/dwalsh/SELinux/Presentations/ManageRHEL5.pdf > > This book: > http://www.selinuxbyexample.com/ > > These: > http://docs.fedoraproject.org/selinux-user-guide/f11/en-US/ > > http://docs.fedoraproject.org/selinux-managing-confined-services-guide/en-US/F11/html/ > > And this: > http://www.nsa.gov/research/selinux/ Thanks a lot for all links you have put up together for me. I believe I already have some of them, if not all of them. I was wondering if there is some academic research into SELinux (other than Flux / Flask) as other resources / references might be deemed as unsubstantiated. > > > hth > Thanks, Zbynek > > > > > Kind regards, > > > > Zbynek > > > -- > > fedora-selinux-list mailing list > > fedora-selinux-list at redhat.com > > https://www.redhat.com/mailman/listinfo/fedora-selinux-list > > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list > -------------- next part -------------- An HTML attachment was scrubbed... URL: From roberto.sassu at polito.it Mon Sep 28 15:44:09 2009 From: roberto.sassu at polito.it (Roberto Sassu) Date: Mon, 28 Sep 2009 17:44:09 +0200 Subject: Custom labeling network interfaces In-Reply-To: <20090928133822.GA10400@notebook3.grift.internal> References: <200909261715.36658.myrobmail@gmail.com> <200909281506.48954.roberto.sassu@polito.it> <20090928133822.GA10400@notebook3.grift.internal> Message-ID: <200909281744.13305.roberto.sassu@polito.it> On Monday 28 September 2009 15:38:23 Dominick Grift wrote: > On Mon, Sep 28, 2009 at 03:06:48PM +0200, Roberto Sassu wrote: > > I downloaded the source policy and i created this patch: > > ---------------- > > --- serefpolicy-3.6.12/policy/modules/kernel/corenetwork.te.in.old > > 2009-09-28 12:09:24.617041763 +0200 > > +++ serefpolicy-3.6.12/policy/modules/kernel/corenetwork.te.in > > 2009-09-28 12:09:51.410362006 +0200 > > @@ -261,6 +261,11 @@ network_interface(lo, lo,s0 - mls_system > > typealias netif_t alias { lo_netif_t netif_lo_t }; > > ') > > > > +build_option(`enable_mls',` > > +network_interface(eth0, eth0,s0 - mls_systemhigh) > > +') > > + > > + > > ######################################## > > # > > # Unconfined access to this module > > ----------------- > > > > > > Then i recompiled the whole policy using the spec file, i installed it > > and i relabeled the entire file system. > > The problem is that i'm not able to use the new interfaces, for example > > "corenet_tcp_sendrecv_eth0_if". When building a custom module that calls > > it, the following message appears: > > > > ----------------- > > Compiling targeted userdom module > > /usr/bin/checkmodule: loading policy configuration from tmp/userdom.tmp > > userdom.te":64:ERROR 'syntax error' at token > > 'corenet_tcp_sendrecv_eth0_if' on line 151624: > > corenet_tcp_sendrecv_eth0_if(sshdlow_t) > > #line 64 > > /usr/bin/checkmodule: error(s) encountered while parsing configuration > > make: *** [tmp/userdom.mod] Error 1 > > ----------------- > > > > In the patch described above i miss the line typealias netif.... because > > i suppose that if eth0_netif_t is an alias of netif_t, allowing an access > > rule for the last type means granting the privilege for all interfaces. > > I think your declaration is wrong: > > Try this instead: > > type netif_eth0_t, netif_type; > sid netif gen_context(system_u:object_r:netif_eth0_t,s0 - mls_systemhigh) > > The syntax error signals that you interface call does not exists > corenet_tcp_sendrecv_eth0_if > > That would make sense, since the declaration was wrong (non existant) > > .. Although i am not sure, it has been a long time since i tried it. > Sorry, i tried to use the 2 line above but the compile process fails with message: --------------------- Compiling targeted base module /usr/bin/checkmodule -M -U allow base.conf -o tmp/base.mod /usr/bin/checkmodule: loading policy configuration from base.conf tmp/rolemap.conf":1320:ERROR 'The context for SID netif is multiply defined' at token 'sid' on line 1006589: sid netif system_u:object_r:netif_eth0_t:s0 sid devnull system_u:object_r:null_device_t:s0 /usr/bin/checkmodule: error(s) encountered while parsing configuration make: *** [tmp/base.mod] Error 1 error: Bad exit status from /var/tmp/rpm-tmp.JFoPCq (%install) ---------------------- Instead i noted that when applying my patch in the file corenetwork.if, there is present this interface: interface(`corenet_tcp_sendrecv_eth0_if',` gen_require(` type eth0_netif_t; ') allow $1 eth0_netif_t:netif { tcp_send tcp_recv egress ingress }; ') > > Lastly i have another question about the ssh server and its ability to > > set new domains for processes of remote users. > > I want to have two different servers, one which is able to set all > > possible domains for the shell, another which have a capability to set > > only a subset of domain. To accomplish this task i used the interface > > "ssh_server_template", i copied from the file ssh.te all rules that > > involve the domain sshd_t and i added the following lines: > > > > ------------------- > > interface(`ssh_server_users_interaction',` > > gen_require(` > > type $1_t, shell_exec_t; > > type $2; > > ') > > > > allow $1_t $2: process transition; > > allow $2 $1_t:process sigchld; > > allow $1_t $2:process { siginh }; > > dontaudit $1_t $2:process { noatsecure }; > > ') > > ------------------- > > > > Is this correct or there's a way for that to be circumvented? > > Thanks for replies. > > Not sure about this one. sorry. Did you test it? > Yes, but unfortunately i've not considered that remote accesses were denied due to a bad configuration of mls levels. Then, using the ssh_server_template, the ssh server is always able to transition to whatever domain. I'm currently finding what rules must be commented to explicitly define domains transitions. > > On Saturday 26 September 2009 18:29:48 Dominick Grift wrote: > > > On Sat, Sep 26, 2009 at 05:15:36PM +0200, Roberto Sassu wrote: > > > > Hi all > > > > > > > > i want to create a set of rules that allow the administrator to > > > > decide the network interfaces on which daemons can listen to. > > > > > > > > To do this i created a custom policy module to define the type > > > > eth0_netif_t which is bound to the eth0 interface. > > > > > > > > type eth0_netif_t, netif_type; > > > > typeattribute eth0_netif_t netif_type; > > > > > > > > > > > > ifdef(`enable_mls',` > > > > > > > > gen_require(`type unlabeled_t;') > > > > netifcon eth0 gen_context(system_u:object_r:eth0_netif_t,s0 - > > > > mls_systemhigh) gen_context(system_u:object_r:unlabeled_t,s0 - > > > > mls_systemhigh) > > > > > > > > ') > > > > > > > > Next, i executed the following command: > > > > > > > > semanage interface -a -t eth0_netif_t eth0 > > > > > > > > Then, without adding extra rules i tried to start the sshd daemon on > > > > this interface and the operation was successful. I see with the apol > > > > utility that sshd is allowed to bind on the generic interface netif_t > > > > but not on eth0_netif_t. > > > > > > > > How it's possible to explicitly grant the permission to listen on > > > > eth0 for each daemon which needs it? > > > > > > These types are declared in the corenetwork source policy, which is > > > compiled into the base module. For you to be able to implement policy > > > with regard to how domains can interact with network interface object > > > type you would have to edit the policy. For example: > > > > > > This is from apache.te: > > > > > > corenet_tcp_sendrecv_all_if(httpd_t) > > > corenet_udp_sendrecv_all_if(httpd_t) > > > > > > Which means that httpd_t can send and receive tcp and udp packets using > > > all network interfaces. So these rule would have to be removed/replaced > > > by rules that explicitly define how and which network interfaces > > > httpd_t can access. > > > > > > This would have to be done for each domain that has access to network > > > interfaces via the "all_if" interfaces. > > > > > > So if you really want to make this work, you should download the > > > selinux-policy.src.rpm corresponding to the selinux-policy version > > > that you currently have installed. Then extract the source rpm and prep > > > the source ( apply the included patch(es) to the extracted included > > > serefpolicy.tgz. > > > > > > Then you would have to declare your custom interface object type in > > > corenetwork.te.in and remove the "all_if" interface calls from each > > > module that calls it. Replace it with rules the you want to enforce. > > > When you build the policy interfaces will be automatically created by > > > the corenetwork module. You can call these interfaces instead of using > > > "local policy" > > > > > > After you have modified the policy you would "clean the source" and > > > repackage it (serefpolicy.tgz). Since you have already applies any > > > included patches by redhat when you have "preparated the source" you > > > no longer have to patch the source, thus you can remove any lines where > > > it refers to 'patch' from the selinux-policy.spec that is included with > > > the source rpm. > > > > > > Also "bump" the version in the spec file so that it can be installed > > > without forcing installation. > > > > > > Then you would simply rebuild the selinux-policy.src.rpm using > > > rpm-devtools (rpmbuild -ba selinux-policy.spec), and update your policy > > > with rpm -Uvh selinux-policy*.rpm > > > > > > The problem with this method though is that from that point you are the > > > maintainer of your implemented policy, meaning you can no longer > > > blindly update from the redhat packages if you do not want your > > > modification to be resetted. > > > > > > With EL5 this is not such a big problem since EL5 selinux-policy does > > > not get updated very often. > > > > > > hth > > > > > > > Thanks in advance for replies. > > > > > > > > -- > > > > fedora-selinux-list mailing list > > > > fedora-selinux-list at redhat.com > > > > https://www.redhat.com/mailman/listinfo/fedora-selinux-list > > > > -- > > fedora-selinux-list mailing list > > fedora-selinux-list at redhat.com > > https://www.redhat.com/mailman/listinfo/fedora-selinux-list > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2153 bytes Desc: not available URL: From domg472 at gmail.com Mon Sep 28 15:49:32 2009 From: domg472 at gmail.com (Dominick Grift) Date: Mon, 28 Sep 2009 17:49:32 +0200 Subject: Clamav/SeLinux, issue with system call recvmsg, and auxilary data. In-Reply-To: <200909281622.19118.d.rye@roadtech.co.uk> References: <200909281622.19118.d.rye@roadtech.co.uk> Message-ID: <20090928154931.GC10400@notebook3.grift.internal> On Mon, Sep 28, 2009 at 04:22:18PM +0100, J. David Rye of Roadtech wrote: > > > Hello All > > I triggered this issue with clamav/clamav-milter 0.95.2 from rpmforge running on a test box with Centos 5.3 > > Clamd opens a socket /var/run/clamav/clamd.sock to accept requests to scan things. > > ls -Z /var/run/clamav/clamd.sock > srwxrwxrwx clamav clamav root:object_r:clamd_var_run_t /var/run/clamav/clamd.sock > > Requests are read using the system call recvmsg, this allows for the passing auxiliary control data. > > Clamav-milter 0.95.2 uses this to pass a handle to the temp file containing the data to be scanned > > With SeLinux set to targeted enforcing, this call reads and returns the normal data fine, but returns with the > flag MSG_CTRUNC set. > > according to the man page this is > "indicates that some control data were discarded due to lack of space in the buffer for ancillary data." > > clamd responded by closing the socket, clamav-milter responded to the closed socket by looping a 100% CPU. :-( > > > Running the audit log through audit2allow suggests > > grep clam /var/log/audit/audit.log | audit2allow -m local > local.te > [root at fallback0 selinux]# cat local.te > > module local 1.0; > > require { > type initrc_tmp_t; > type proc_t; > type sysctl_kernel_t; > type clamd_t; > class dir search; > class file { read write getattr }; > } > > #============= clamd_t ============== > allow clamd_t initrc_tmp_t:file { read write getattr }; > allow clamd_t proc_t:file { read getattr }; > allow clamd_t sysctl_kernel_t:dir search; > allow clamd_t sysctl_kernel_t:file read; The first line means that something runs in the initrc_t init script domain. Either the program executable file for this process is mislabeled or there is no policy for this init daemon. ps auxZ | grep initrc_t The second and third / fourth line signal that clamd_t needs read access to read_system_state and read_sysctls. You could extend the clamd domain with a custom policy module to implement this echo "policy_module(myclamd, 0.0.1)" >> myclamd.te; echo "require { type clamd_t; }" > myclamd.te; echo "kernel_read_system_state(clamd_t)" > myclamd.te; echo "kernel_read_kernel_sysctls(clamd_t)" > myclamd.te; make -f /usr/share/selinux/devel/Makefile myclamd.pp sudo semodule -i myclamd.pp > > > The allow clamd_t proc_t:file { read getattr }; looks to relate to reading /proc/meminfo > > allow clamd_t sysctl_kernel_t:dir search; > allow clamd_t sysctl_kernel_t:file read; > Look to relate to these log entries > type=AVC msg=audit(1254139856.343:48724): avc: denied { search } for pid=14771 comm="clamd" name="kernel" dev=proc ino=-268435416 scontext=root:system_r:clamd_t:s0 tcontext=system_u:object_r:sysctl_kernel_t:s0 tclass=dir > type=AVC msg=audit(1254139856.343:48724): avc: denied { read } for pid=14771 comm="clamd" name="ngroups_max" dev=proc ino=-268435368 scontext=root:system_r:clamd_t:s0 tcontext=system_u:object_r:sysctl_kernel_t:s0 tclass=file > type=AVC msg=audit(1254149740.665:48885): avc: denied { search } for pid=1261 comm="clamd" name="kernel" dev=proc ino=-268435416 scontext=root:system_r:clamd_t:s0 tcontext=system_u:object_r:sysctl_kernel_t:s0 tclass=dir > > This if I have figured it out right relate to something that clamd is calling in turn trying to read /proc/sys/kernel/ngroups_max > > > So by elimination > allow clamd_t initrc_tmp_t:file { read write getattr }; > > Must relate to the the use of auxiliary data with the socket, and the following log entries but I do not see why. > Can anyone explain? > > type=AVC msg=audit(1254150147.188:48924): avc: denied { read write } for pid=1288 comm="clamd" path=2F746D702F636C616D61762D3063666237656532666331656139656636323364373463316236626532623735202864656C6574656429 dev=dm-0 ino=34668546 scontext=root:system_r:clamd_t:s0 tcontext=root:object_r:initrc_tmp_t:s0 tclass=file > type=AVC msg=audit(1254150153.681:48925): avc: denied { read write } for pid=1288 comm="clamd" path=2F746D702F636C616D61762D3336316332323033323138613239633865363633633937303962663133363664202864656C6574656429 dev=dm-0 ino=34668546 scontext=root:system_r:clamd_t:s0 tcontext=root:object_r:initrc_tmp_t:s0 tclass=file > type=AVC msg=audit(1254150177.903:48926): avc: denied { read write } for pid=1288 comm="clamd" path=2F746D702F636C616D61762D3366636162623138633237636231383466643064656630643838353063363933202864656C6574656429 dev=dm-0 ino=34668546 scontext=root:system_r:clamd_t:s0 tcontext=root:object_r:initrc_tmp_t:s0 tclass=file > type=AVC msg=audit(1254150188.366:48927): avc: denied { read write } for pid=1288 comm="clamd" path=2F746D702F636C616D61762D6366393131623632353130333564353832656435396466663136373362626131202864656C6574656429 dev=dm-0 ino=34668546 scontext=root:system_r:clamd_t:s0 tcontext=root:object_r:initrc_tmp_t:s0 tclass=file > type=AVC msg=audit(1254150220.428:48928): avc: denied { read write } for pid=1288 comm="clamd" path=2F746D702F636C616D61762D3931633534623761393630653531386630363539653033363537303937323135202864656C6574656429 dev=dm-0 ino=34668546 scontext=root:system_r:clamd_t:s0 tcontext=root:object_r:initrc_tmp_t:s0 tclass=file > > > Yours > > J. David Rye > > > > > > > > > > > > ************************************************************************* > This e-mail is confidential and may be legally privileged. It is intended > solely for the use of the individual(s) to whom it is addressed. Any > content in this message is not necessarily a view or statement from Road > Tech Computer Systems Limited but is that of the individual sender. If > you are not the intended recipient, be advised that you have received > this e-mail in error and that any use, dissemination, forwarding, > printing, or copying of this e-mail is strictly prohibited. We use > reasonable endeavours to virus scan all e-mails leaving the company but > no warranty is given that this e-mail and any attachments are virus free. > You should undertake your own virus checking. The right to monitor e-mail > communications through our networks is reserved by us > > Road Tech Computer Systems Ltd. Shenley Hall, Rectory Lane, Shenley, > Radlett, Hertfordshire, WD7 9AN. - VAT Registration No GB 449 3582 17 > Registered in England No: 02017435, Registered Address: Charter Court, > Midland Road, Hemel Hempstead, Hertfordshire, HP2 5GE. > ************************************************************************* > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From zbynek.houska at gmail.com Mon Sep 28 15:49:37 2009 From: zbynek.houska at gmail.com (Zbynek Houska) Date: Mon, 28 Sep 2009 16:49:37 +0100 Subject: Final year project ideas In-Reply-To: <200909281123.22364.russell@coker.com.au> References: <761f67170909271125t493e9e2dx96158194dbd2f279@mail.gmail.com> <200909281123.22364.russell@coker.com.au> Message-ID: <761f67170909280849q5b8a1225p6c709f8cfbfdaf2a@mail.gmail.com> On Mon, Sep 28, 2009 at 2:23 AM, Russell Coker wrote: > On Mon, 28 Sep 2009, Zbynek Houska wrote: > > write a few (new) policies for software of my choice. I intend to use > > honeypots running Fedora 11 as my base system. However, I'm not sure if > > college class B network will produce conclusive results. > > > > Thus, I would appreciate support, guidance and comments from (seasoned) > > SELinux gurus, developers and practitioners on this list in order to > point > > me in the right direction when it comes to sourcing literature, white > > papers, research work other people might already have conducted and > > overcoming pitfalls related to such testing environments. > > Firstly firewall all traffic from the system in question - other than that > which is required for it to be vulnerable to the attacks you desire. If > you > allow ICMP echo access then someone will try and ping-flood other systems. > If you allow outbound TCP connections then your system may be used to > compromise others. > I think I will be using private VLANs on the switch (aka switchport protected / port protected on Cisco switches) which will limit that box to be able to talk to the gateway only, hence making it impossible to compromise other systems on same subnet. Firewall of some kind will have to be used too as for example outgoing SMTP traffic from that box isn't something I would like to see. > > Probably the best way to run honeypots is to use Xen or KVM to run virtual > machines. This means that you have lots of good options for monitoring the > machines while they are attacked. But don't assume that Xvn or KVM is > flawless - IE don't have any sensitive data on the same physical machine. > Yes, I was thinking of exactly the same - using either KVM or UML - will have to decide what way is the most feasible one. > > The purpose of a honeypot is to attract attack, running the latest versions > of > software is going to make it more difficult for attackers and partially > defeats this goal. Maybe running Fedora 10 (or earlier) with no updates > would be a better option. Of course you will probably want to back-port > the > latest SE Linux policy before you do this (which shouldn't be difficult). > Good point here, I didn't thought it through. > > It's been a while since anyone ran a SE Linux Play Machine on Fedora, I > would > be happy to offer detailed advice and some testing if you want to run one. > I wasn't even thinking about making 'play machine(s)' as I hoped to bring some randomness into it by making it unannounced and hope for the best - i.e. somebody trying to attack the box by scanning for running services. But I have to admit, the way you proposed is more controllable and will possibly yield more predictable results (rather than wait for a random attack). Do you have much experience in setting up and running such boxes? If so, would you mind shedding some light on the entire process, please? However, I reckon I will need to announce a kind of 'hackathon' (on this list?) in order to achieve some results as I can't imagine to be impartial if I do the attacks myself... Regards, Z. > -- > russell at coker.com.au > http://etbe.coker.com.au/ My Main Blog > http://doc.coker.com.au/ My Documents Blog > -------------- next part -------------- An HTML attachment was scrubbed... URL: From domg472 at gmail.com Mon Sep 28 15:59:18 2009 From: domg472 at gmail.com (Dominick Grift) Date: Mon, 28 Sep 2009 17:59:18 +0200 Subject: Custom labeling network interfaces In-Reply-To: <200909281744.13305.roberto.sassu@polito.it> References: <200909261715.36658.myrobmail@gmail.com> <200909281506.48954.roberto.sassu@polito.it> <20090928133822.GA10400@notebook3.grift.internal> <200909281744.13305.roberto.sassu@polito.it> Message-ID: <20090928155917.GD10400@notebook3.grift.internal> On Mon, Sep 28, 2009 at 05:44:09PM +0200, Roberto Sassu wrote: > On Monday 28 September 2009 15:38:23 Dominick Grift wrote: > > On Mon, Sep 28, 2009 at 03:06:48PM +0200, Roberto Sassu wrote: > > > I downloaded the source policy and i created this patch: > > > ---------------- > > > --- serefpolicy-3.6.12/policy/modules/kernel/corenetwork.te.in.old > > > 2009-09-28 12:09:24.617041763 +0200 > > > +++ serefpolicy-3.6.12/policy/modules/kernel/corenetwork.te.in > > > 2009-09-28 12:09:51.410362006 +0200 > > > @@ -261,6 +261,11 @@ network_interface(lo, lo,s0 - mls_system > > > typealias netif_t alias { lo_netif_t netif_lo_t }; > > > ') > > > > > > +build_option(`enable_mls',` > > > +network_interface(eth0, eth0,s0 - mls_systemhigh) > > > +') > > > + > > > + > > > ######################################## > > > # > > > # Unconfined access to this module > > > ----------------- > > > > > > > > > Then i recompiled the whole policy using the spec file, i installed it > > > and i relabeled the entire file system. > > > The problem is that i'm not able to use the new interfaces, for example > > > "corenet_tcp_sendrecv_eth0_if". When building a custom module that calls > > > it, the following message appears: > > > > > > ----------------- > > > Compiling targeted userdom module > > > /usr/bin/checkmodule: loading policy configuration from tmp/userdom.tmp > > > userdom.te":64:ERROR 'syntax error' at token > > > 'corenet_tcp_sendrecv_eth0_if' on line 151624: > > > corenet_tcp_sendrecv_eth0_if(sshdlow_t) > > > #line 64 > > > /usr/bin/checkmodule: error(s) encountered while parsing configuration > > > make: *** [tmp/userdom.mod] Error 1 > > > ----------------- > > > > > > In the patch described above i miss the line typealias netif.... because > > > i suppose that if eth0_netif_t is an alias of netif_t, allowing an access > > > rule for the last type means granting the privilege for all interfaces. > > > > I think your declaration is wrong: > > > > Try this instead: > > > > type netif_eth0_t, netif_type; > > sid netif gen_context(system_u:object_r:netif_eth0_t,s0 - mls_systemhigh) > > > > The syntax error signals that you interface call does not exists > > corenet_tcp_sendrecv_eth0_if > > > > That would make sense, since the declaration was wrong (non existant) > > > > .. Although i am not sure, it has been a long time since i tried it. > > > Sorry, i tried to use the 2 line above but the compile process fails with > message: > > --------------------- > Compiling targeted base module > /usr/bin/checkmodule -M -U allow base.conf -o tmp/base.mod > /usr/bin/checkmodule: loading policy configuration from base.conf > tmp/rolemap.conf":1320:ERROR 'The context for SID netif is multiply defined' at > token 'sid' on line 1006589: > sid netif system_u:object_r:netif_eth0_t:s0 > sid devnull system_u:object_r:null_device_t:s0 > /usr/bin/checkmodule: error(s) encountered while parsing configuration > make: *** [tmp/base.mod] Error 1 > error: Bad exit status from /var/tmp/rpm-tmp.JFoPCq (%install) > ---------------------- > > Instead i noted that when applying my patch in the file corenetwork.if, there > is present this interface: > > interface(`corenet_tcp_sendrecv_eth0_if',` > gen_require(` > type eth0_netif_t; > ') > > allow $1 eth0_netif_t:netif { tcp_send tcp_recv egress ingress }; > ') > OK, well the interface seems correct but your call to it throws a syntax error. I guess this might in that case be related to type sshdlow_t. It might be a good idea to check whether that type is a usable domain type. > > > > Lastly i have another question about the ssh server and its ability to > > > set new domains for processes of remote users. > > > I want to have two different servers, one which is able to set all > > > possible domains for the shell, another which have a capability to set > > > only a subset of domain. To accomplish this task i used the interface > > > "ssh_server_template", i copied from the file ssh.te all rules that > > > involve the domain sshd_t and i added the following lines: > > > > > > ------------------- > > > interface(`ssh_server_users_interaction',` > > > gen_require(` > > > type $1_t, shell_exec_t; > > > type $2; > > > ') > > > > > > allow $1_t $2: process transition; > > > allow $2 $1_t:process sigchld; > > > allow $1_t $2:process { siginh }; > > > dontaudit $1_t $2:process { noatsecure }; > > > ') > > > ------------------- > > > > > > Is this correct or there's a way for that to be circumvented? > > > Thanks for replies. > > > > Not sure about this one. sorry. Did you test it? > > > > Yes, but unfortunately i've not considered that remote accesses were denied > due to a bad configuration of mls levels. > Then, using the ssh_server_template, the ssh server is always able to > transition to whatever domain. I'm currently finding what rules must be > commented to explicitly define domains transitions. > > > > > > On Saturday 26 September 2009 18:29:48 Dominick Grift wrote: > > > > On Sat, Sep 26, 2009 at 05:15:36PM +0200, Roberto Sassu wrote: > > > > > Hi all > > > > > > > > > > i want to create a set of rules that allow the administrator to > > > > > decide the network interfaces on which daemons can listen to. > > > > > > > > > > To do this i created a custom policy module to define the type > > > > > eth0_netif_t which is bound to the eth0 interface. > > > > > > > > > > type eth0_netif_t, netif_type; > > > > > typeattribute eth0_netif_t netif_type; > > > > > > > > > > > > > > > ifdef(`enable_mls',` > > > > > > > > > > gen_require(`type unlabeled_t;') > > > > > netifcon eth0 gen_context(system_u:object_r:eth0_netif_t,s0 - > > > > > mls_systemhigh) gen_context(system_u:object_r:unlabeled_t,s0 - > > > > > mls_systemhigh) > > > > > > > > > > ') > > > > > > > > > > Next, i executed the following command: > > > > > > > > > > semanage interface -a -t eth0_netif_t eth0 > > > > > > > > > > Then, without adding extra rules i tried to start the sshd daemon on > > > > > this interface and the operation was successful. I see with the apol > > > > > utility that sshd is allowed to bind on the generic interface netif_t > > > > > but not on eth0_netif_t. > > > > > > > > > > How it's possible to explicitly grant the permission to listen on > > > > > eth0 for each daemon which needs it? > > > > > > > > These types are declared in the corenetwork source policy, which is > > > > compiled into the base module. For you to be able to implement policy > > > > with regard to how domains can interact with network interface object > > > > type you would have to edit the policy. For example: > > > > > > > > This is from apache.te: > > > > > > > > corenet_tcp_sendrecv_all_if(httpd_t) > > > > corenet_udp_sendrecv_all_if(httpd_t) > > > > > > > > Which means that httpd_t can send and receive tcp and udp packets using > > > > all network interfaces. So these rule would have to be removed/replaced > > > > by rules that explicitly define how and which network interfaces > > > > httpd_t can access. > > > > > > > > This would have to be done for each domain that has access to network > > > > interfaces via the "all_if" interfaces. > > > > > > > > So if you really want to make this work, you should download the > > > > selinux-policy.src.rpm corresponding to the selinux-policy version > > > > that you currently have installed. Then extract the source rpm and prep > > > > the source ( apply the included patch(es) to the extracted included > > > > serefpolicy.tgz. > > > > > > > > Then you would have to declare your custom interface object type in > > > > corenetwork.te.in and remove the "all_if" interface calls from each > > > > module that calls it. Replace it with rules the you want to enforce. > > > > When you build the policy interfaces will be automatically created by > > > > the corenetwork module. You can call these interfaces instead of using > > > > "local policy" > > > > > > > > After you have modified the policy you would "clean the source" and > > > > repackage it (serefpolicy.tgz). Since you have already applies any > > > > included patches by redhat when you have "preparated the source" you > > > > no longer have to patch the source, thus you can remove any lines where > > > > it refers to 'patch' from the selinux-policy.spec that is included with > > > > the source rpm. > > > > > > > > Also "bump" the version in the spec file so that it can be installed > > > > without forcing installation. > > > > > > > > Then you would simply rebuild the selinux-policy.src.rpm using > > > > rpm-devtools (rpmbuild -ba selinux-policy.spec), and update your policy > > > > with rpm -Uvh selinux-policy*.rpm > > > > > > > > The problem with this method though is that from that point you are the > > > > maintainer of your implemented policy, meaning you can no longer > > > > blindly update from the redhat packages if you do not want your > > > > modification to be resetted. > > > > > > > > With EL5 this is not such a big problem since EL5 selinux-policy does > > > > not get updated very often. > > > > > > > > hth > > > > > > > > > Thanks in advance for replies. > > > > > > > > > > -- > > > > > fedora-selinux-list mailing list > > > > > fedora-selinux-list at redhat.com > > > > > https://www.redhat.com/mailman/listinfo/fedora-selinux-list > > > > > > -- > > > fedora-selinux-list mailing list > > > fedora-selinux-list at redhat.com > > > https://www.redhat.com/mailman/listinfo/fedora-selinux-list > > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From dwalsh at redhat.com Mon Sep 28 16:20:42 2009 From: dwalsh at redhat.com (Daniel J Walsh) Date: Mon, 28 Sep 2009 16:20:42 -0000 Subject: Memory protection and system-config-securitylevel In-Reply-To: <1178393904.2839.11.camel@chello087207029077.chello.pl> References: <1178137738.7325.23.camel@chello087207029077.chello.pl> <463B51B1.2030109@redhat.com> <1178393904.2839.11.camel@chello087207029077.chello.pl> Message-ID: <46407914.9080605@redhat.com> Kamil J. Dudek wrote: > Dnia 04-05-2007, pi? o godzinie 11:30 -0400, Daniel J Walsh napisa?(a): > >> Kamil wrote: >> >>> Hello everybody >>> Forgive me, if this subject has already been mentioned here, but I >>> simply couldn't find answer anywhere. >>> >>> Few days ago I started system-config-securitylevel. I found something >>> interesting in "Modify SELinux policies". A memory protection - there >>> are four options in there. Two of them are enabled, with a description >>> that if having this enabled is required by some program, it should be >>> reported to bugzilla. I didn't do it, because of very strange effects >>> after turning it off. >>> >>> Disabling >>> "Allow all executable files to map memory areas as executable and >>> readable, which is dangerous and such program should be reported to >>> bugzilla" >>> and >>> "Allow all executable files to mark stack as executable.That shouldn't >>> ever be required" >>> option(translation from polish) made system act very strange. First >>> thing I've observed was that Kobo game stopped working. GMPC stopped >>> playing. Also stuff outside of Fedora like Java and NVidia drivers >>> failed. So I should have "reported to bugzilla" to many application to >>> make it have any sense. Such bug report would be only annoying but >>> according to system-config-securitylevel... >>> >>> >>> >> Java Applications can be labeled java_exec_t (chcon -t java_exec_t >> PATHTOAPP) Please tell me the path of these apps, so I can set them to >> default. Which will allow them to have this priv. NVidia should be >> told to fix their drivers. (Or open source them, their choice :^)) >> >> These memory checks are described here >> SELinux Memory Protection Tests >> >> >> The goal is to move towards, eliminating Writable/Executable memory to >> help protect systems. >> For now if you can run with these checked off, you are more secure. We >> realize that lots of apps are either broken or not labeled correctly. >> So we need to get the app vendors to fix their apps and to fix the >> labeling when it is wrong in SELinux. >> > > I have enabled only "Allow all executable files to mark stack as > executable.That shouldn't ever be required". And everything except > external NVidia drivers seems to work fine. The nv driver doesn't make > any surprises. But when I disable even that, programs like Kobo Deluxe > and glxgears return "Permission denied" error. Should I report this > programs to Bugzilla or ignore that hint? > Please attach the avc messages from /var/log/audit/audit.log >> >>> What is it with these two options? To make everything work properly they >>> should be enabled, but their description that they should be disabled is >>> confusing. >>> >>> Thank you and forgive me any mess I've done by this post >>> >>> >>> From method at manicmethod.com Mon Sep 28 19:48:29 2009 From: method at manicmethod.com (Joshua Brindle) Date: Mon, 28 Sep 2009 15:48:29 -0400 Subject: The SELinux Documentation Project [Request for topics] Message-ID: <4AC1130D.8000601@manicmethod.com> As we discussed at Linux Plumbers Conference during the 'Making SELinux Easier to Use" talk we have some document deficiencies in the SELinux project. I volunteered to start an SELinux Documentation Project. The primary purpose of the project would be to get as much documentation as possible on the selinuxproject.org wiki, organized in a fashion that users can understand and consume easily. As I admitted before, we, the developers, are not always the best people to judge what documentation users need and therefore am requesting users, hopefully from different backgrounds and environments, tell us what documentation they feel is lacking, what questions they've been asked or have asked themselves and couldn't find documentation for. I think we need basic documentation that tells about SELinux (both beginner and advanced), howto's for specific things (using secmark, using netlabel, etc) and a set of short 'recipes' to accomplish simple tasks. There are documents all over the place with various information, as well as blog entries and mailing list archives but the effort here is to consolidate all those resources onto selinuxproject.org. I'd also like to see volunteers in the community to help out with the documentation effort, I know quite a few people already write things like this on blogs, etc and it would be great to see that information moved/copied onto selinuxproject.org. Users: Please, if you are a user and have run in to lack of documentation respond to this thread, or privately if you aren't comfortable talking on list so that we can collect what the biggest deficiencies are and get to writing documentation as soon as possible. Thanks. From domg472 at gmail.com Mon Sep 28 20:26:28 2009 From: domg472 at gmail.com (Dominick Grift) Date: Mon, 28 Sep 2009 22:26:28 +0200 Subject: The SELinux Documentation Project [Request for topics] In-Reply-To: <4AC1130D.8000601@manicmethod.com> References: <4AC1130D.8000601@manicmethod.com> Message-ID: <20090928202627.GE10400@notebook3.grift.internal> On Mon, Sep 28, 2009 at 03:48:29PM -0400, Joshua Brindle wrote: > As we discussed at Linux Plumbers Conference during the 'Making > SELinux Easier to Use" talk we have some document deficiencies in > the SELinux project. > > I volunteered to start an SELinux Documentation Project. The primary > purpose of the project would be to get as much documentation as > possible on the selinuxproject.org wiki, organized in a fashion that > users can understand and consume easily. > > As I admitted before, we, the developers, are not always the best > people to judge what documentation users need and therefore am > requesting users, hopefully from different backgrounds and > environments, tell us what documentation they feel is lacking, what > questions they've been asked or have asked themselves and couldn't > find documentation for. > > I think we need basic documentation that tells about SELinux (both > beginner and advanced), howto's for specific things (using secmark, > using netlabel, etc) and a set of short 'recipes' to accomplish > simple tasks. > > There are documents all over the place with various information, as > well as blog entries and mailing list archives but the effort here > is to consolidate all those resources onto selinuxproject.org. > > I'd also like to see volunteers in the community to help out with > the documentation effort, I know quite a few people already write > things like this on blogs, etc and it would be great to see that > information moved/copied onto selinuxproject.org. > > > Users: > > Please, if you are a user and have run in to lack of documentation > respond to this thread, or privately if you aren't comfortable > talking on list so that we can collect what the biggest deficiencies > are and get to writing documentation as soon as possible. > Also a lot of frequently asked questions are answered really well on the maillists. Maybe we can pick the best from there and create a FAQ with a selection of those. My blog posts, e-mails and etcetera can be used/modified/redistributed by anyone as far as i am concerned. There are no restrictions at all. I have plenty things to talk about but i have alteast two problems: 1. my writing skills. 2. need specific topics, so that i can write "to the point" articles and not pages full of dull material where halfway i lost focus on the actual topic. If there are people reading this that have experience with writing documentation etcetera and that want to help create documentation (and in the process learn a bit about SELinux), please let us know. > > Thanks. > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From yersinia.spiros at gmail.com Tue Sep 29 08:10:53 2009 From: yersinia.spiros at gmail.com (yersinia) Date: Tue, 29 Sep 2009 10:10:53 +0200 Subject: The SELinux Documentation Project [Request for topics] In-Reply-To: <4AC1130D.8000601@manicmethod.com> References: <4AC1130D.8000601@manicmethod.com> Message-ID: On Mon, Sep 28, 2009 at 9:48 PM, Joshua Brindle wrote: > As we discussed at Linux Plumbers Conference during the 'Making SELinux > Easier to Use" talk we have some document deficiencies in the SELinux > project. > > I volunteered to start an SELinux Documentation Project. The primary > purpose of the project would be to get as much documentation as possible on > the selinuxproject.org wiki, organized in a fashion that users can > understand and consume easily. > > As I admitted before, we, the developers, are not always the best people to > judge what documentation users need and therefore am requesting users, > hopefully from different backgrounds and environments, tell us what > documentation they feel is lacking, what questions they've been asked or > have asked themselves and couldn't find documentation for. > > I think we need basic documentation that tells about SELinux (both beginner > and advanced), howto's for specific things (using secmark, using netlabel, > etc) and a set of short 'recipes' to accomplish simple tasks. > > There are documents all over the place with various information, as well as > blog entries and mailing list archives but the effort here is to consolidate > all those resources onto selinuxproject.org. > > Great. This is probably one of the best things to do for Selinux. > I'd also like to see volunteers in the community to help out with the > documentation effort, I know quite a few people already write things like > this on blogs, etc and it would be great to see that information > moved/copied onto selinuxproject.org. > > > Users: > > Please, if you are a user and have run in to lack of documentation respond > to this thread, or privately if you aren't comfortable talking on list so > that we can collect what the biggest deficiencies are and get to writing > documentation as soon as possible. > > > Thanks. > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mgrepl at redhat.com Tue Sep 29 11:28:11 2009 From: mgrepl at redhat.com (Miroslav Grepl) Date: Tue, 29 Sep 2009 13:28:11 +0200 Subject: Can I allow console_type_t to access pppd_t? In-Reply-To: <10547869.697791254102612911.JavaMail.coremail@bj126app25.126.com> References: <10547869.697791254102612911.JavaMail.coremail@bj126app25.126.com> Message-ID: <4AC1EF4B.9010403@redhat.com> On 09/28/2009 03:50 AM, chenh wrote: > > Everytime I use adsl connection, AVC alerts: "SELinux is preventing > consoletype (consoletype_t) "read write" pppd_t. " I typed > "audit2allow -a" and saw: > > #============= alsa_t ============== > allow alsa_t file_t:file read; > > #============= consoletype_t ============== > allow consoletype_t file_t:file read; > allow consoletype_t pppd_t:packet_socket { read write }; > > #============= dmesg_t ============== > allow dmesg_t file_t:file read; > > #============= hwclock_t ============== > allow hwclock_t file_t:file read; > > #============= ifconfig_t ============== > allow ifconfig_t file_t:file read; > > #============= mount_t ============== > allow mount_t file_t:file unlink; > > #============= setroubleshootd_t ============== > allow setroubleshootd_t locate_var_lib_t:file read; > Looks like your machine is mislabeled. Could you try to execute: # fixfiles restore # reboot What is your version of selinux-policy. # rpm -q selinux-policy selinux-policy-targeted > There're two rule about consoletype above. Is it safe to add them > using audit2allow? Thanks! > > > ------------------------------------------------------------------------ > "??? ?",????60??? > > ------------------------------------------------------------------------ > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list -------------- next part -------------- An HTML attachment was scrubbed... URL: From dwalsh at redhat.com Tue Sep 29 11:45:14 2009 From: dwalsh at redhat.com (Daniel J Walsh) Date: Tue, 29 Sep 2009 07:45:14 -0400 Subject: Two AVCs In-Reply-To: <4ABA4612.9070800@grifent.com> References: <4ABA3516.9070106@grifent.com> <4ABA373F.2090709@redhat.com> <4ABA4612.9070800@grifent.com> Message-ID: <4AC1F34A.80000@redhat.com> On 09/23/2009 12:00 PM, John Griffiths wrote: > > > Daniel J Walsh wrote: >> On 09/23/2009 07:47 AM, John Griffiths wrote: >> >>> I am using selinux-policy-targeted-3.5.13-71.fc10.noarch on Fedora 10. I am >>> getting these AVCs. They do not seem to inhibit functionality but still >>> troublesome to get the selinux alerts all the time. Are these bugs in the policy >>> or something that will not be addressed and I need to generate local policy? >>> >>> 1) SELinux is preventing postdrop (postfix_postdrop_t) "getattr" httpd_t. >>> >>> Raw Audit Messages : >>> >>> node=elijah.suretrak21.net type=AVC msg=audit(1253716264.867:65886): avc: >>> denied { getattr } for pid=30094 comm="postdrop" path="pipe:[2618550]" >>> dev=pipefs ino=2618550 scontext=system_u:system_r:postfix_postdrop_t:s0 >>> tcontext=system_u:system_r:httpd_t:s0 tclass=fifo_file >>> >>> node=elijah.suretrak21.net type=SYSCALL msg=audit(1253716264.867:65886): >>> arch=40000003 syscall=197 success=no exit=-13 a0=2 a1=bfc167c8 a2=94eff4 >>> a3=2 items=0 ppid=30093 pid=30094 auid=4294967295 uid=48 gid=48 euid=48 >>> suid=48 fsuid=48 egid=90 sgid=90 fsgid=90 tty=(none) ses=4294967295 >>> comm="postdrop" exe="/usr/sbin/postdrop" >>> subj=system_u:system_r:postfix_postdrop_t:s0 key=(null) >>> >> This seems a little strange, is postfix being executed from apache? I would guess that postfix does not communicate with apache via fifo_file, so might be a leak. >> > This happens in conjunction with email being sent by Bugzilla which is of course > being served by apache. Is mail being sent successfully? I believe this is also a leaked file descriptor. >>> 2) SELinux is preventing sendmail (system_mail_t) "read" to >>> /usr/share/GeoIP/GeoIP.dat (usr_t). >>> >>> Raw Audit Messages : >>> >>> node=elijah.suretrak21.net type=AVC msg=audit(1253643380.763:60806): avc: >>> denied { read } for pid=1311 comm="sendmail" >>> path="/usr/share/GeoIP/GeoIP.dat" dev=dm-0 ino=663651 >>> scontext=system_u:system_r:system_mail_t:s0 >>> tcontext=system_u:object_r:usr_t:s0 tclass=file >>> >>> node=elijah.suretrak21.net type=SYSCALL msg=audit(1253643380.763:60806): >>> arch=40000003 syscall=11 success=yes exit=0 a0=9ad05d0 a1=9acfd18 a2=9acfb08 >>> a3=0 items=0 ppid=14784 pid=1311 auid=4294967295 uid=48 gid=48 euid=48 >>> suid=48 fsuid=48 egid=48 sgid=48 fsgid=48 tty=(none) ses=4294967295 >>> comm="sendmail" exe="/usr/sbin/sendmail.postfix" >>> subj=system_u:system_r:system_mail_t:s0 key=(null) >>> >>> >> This one looks like a leak unless something is actually trying to mail /usr/share/GeoIP/GeoIP.dat >> >> > Apache has geoip_module configured, but that is the only place I have GeoIP > configured. Well that GeoIP module is probably sending email or at least opening that file before httpd_t sends mail for another module, revealing the leak. You can add an allow rule using audit2allow, if this is probably not important data. Open a bugzilla with geoip_module to not leak the file. If you are not using the geoip_module, remove it from your apache config. >>> Regards, >>> John Griffiths >>> >>> >>> ------------------------------------------------------------------------ >>> >>> -- >>> fedora-selinux-list mailing list >>> fedora-selinux-list at redhat.com >>> https://www.redhat.com/mailman/listinfo/fedora-selinux-list >>> >> >> You can add custom policy to allow these by executing audit2allow -M mypol >> From dwalsh at redhat.com Tue Sep 29 11:49:08 2009 From: dwalsh at redhat.com (Daniel J Walsh) Date: Tue, 29 Sep 2009 07:49:08 -0400 Subject: New equivalent to browser_confine_xguest? In-Reply-To: <20090923172020.GA18474@wolff.to> References: <20090923172020.GA18474@wolff.to> Message-ID: <4AC1F434.9000308@redhat.com> On 09/23/2009 01:20 PM, Bruno Wolff III wrote: > There used to be a boolean browser_confine_xguest, but there no longer is. > Is there a simple way to not let firefox connect to the network when run > by an xguest user? > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list > > If you relabel firefox to bin_t this should remove this capability. From dwalsh at redhat.com Tue Sep 29 11:52:38 2009 From: dwalsh at redhat.com (Daniel J Walsh) Date: Tue, 29 Sep 2009 07:52:38 -0400 Subject: Logging with bind-chroot In-Reply-To: <4ABB314D.5070209@city-fan.org> References: <4ABB314D.5070209@city-fan.org> Message-ID: <4AC1F506.1030800@redhat.com> On 09/24/2009 04:43 AM, Paul Howarth wrote: > Today's update of bind in F11 suggests adding this line to > /etc/rsyslog.conf to maintain logging with a chroot-ed bind: > > $AddUnixListenSocket /var/named/chroot/dev/log > > For this to work on F-11, I needed to add the following policy module: > > :::::::::::::: > mybindchroot.fc > :::::::::::::: > /var/named/chroot/dev -d gen_context(system_u:object_r:device_t,s0) > /var/named/chroot/dev/log -s gen_context(system_u:object_r:devlog_t,s0) > > :::::::::::::: > mybindchroot.te > :::::::::::::: > policy_module(mybindchroot, 0.0.4) > > require { > type syslogd_t; > } > > # rsyslog needs to search the bind chroot when creating > # /dev/log in the chroot > bind_search_cache(syslogd_t) > > I'd expect the same to apply in other releases too. > > Paul. > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list > > Added to Rawhide, Miroslav, you should add to F11. From dwalsh at redhat.com Tue Sep 29 11:55:51 2009 From: dwalsh at redhat.com (Daniel J Walsh) Date: Tue, 29 Sep 2009 07:55:51 -0400 Subject: AW: Dear List members In-Reply-To: <586576.55669.qm@web24103.mail.ird.yahoo.com> References: <708302.79400.qm@web24104.mail.ird.yahoo.com> <20090925163818.GA14076@notebook3.grift.internal> <20090926011058.3b85d5d5@metropolis.intra.city-fan.org> <586576.55669.qm@web24103.mail.ird.yahoo.com> Message-ID: <4AC1F5C7.8030001@redhat.com> On 09/26/2009 05:56 AM, tarnait wrote: > Hi, > > yeah the console problem was that I use static udev, and the underlying /dev/console didn't have the proper label. Now I'm down to two problems: > > #============= iptables_t ============== > allow iptables_t pppd_t:packet_socket { read write }; Most likely a leaked file descriptor, if you dontaudit this everything should work fine. > > #============= pppd_t ============== > allow pppd_t unconfined_home_dir_t:dir search; Probably can also be dontaudit. pppd_t is just searching the homedir of the process that launched it. > > > as I use iptables to redirect traffic from wlan0 to ppp0 I assue it's safe to add them. > > Thanks for your help, Kindest Regards > > > > > ________________________________ > Von: Paul Howarth > An: Dominick Grift > CC: fedora-selinux-list at redhat.com > Gesendet: Samstag, den 26. September 2009, 02:10:58 Uhr > Betreff: Re: Dear List members > > On Fri, 25 Sep 2009 18:38:20 +0200 > Dominick Grift wrote: > >> On Fri, Sep 25, 2009 at 03:35:52PM +0000, tarnait wrote: >>> type=AVC msg=audit(1253870574.325:17): avc: denied { search } >>> for pid=921 comm="pppd" name="root" dev=sda1 ino=12 >>> scontext=system_u:system_r:pppd_t:s0 >>> tcontext=unconfined_u:object_r:unconfined_home_dir_t:s0 tclass=dir >>> Was caused by: Missing type enforcement (TE) allow rule. >>> >>> You can use audit2allow to generate a loadable >>> module to allow this access. >>> >> >> This also *may* be a labelling issue. pppd wants to search /root >> dir. /root dir has type unconfined_home_dir_t. see if this is >> correct: matchpathcon /root restorecon -R /root >> >> /root usually has type admin_home_t and i do not see any good reason >> why pppd should be able to search it. misconfiguration/misusage maybe? > > pppd looks for ~/.ppprc, so if you're using it as root (e.g. to connect > to your ISP) you're going to see this. Haven't found any way of turning > it off either. > > Paul. > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list > > > > > > > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list From dwalsh at redhat.com Tue Sep 29 11:56:37 2009 From: dwalsh at redhat.com (Daniel J Walsh) Date: Tue, 29 Sep 2009 07:56:37 -0400 Subject: sesearch --neverallow is broken ? In-Reply-To: References: Message-ID: <4AC1F5F5.8000700@redhat.com> On 09/26/2009 11:18 PM, Shintaro Fujiwara wrote: > I typed in F11, > > sesearch --neverallow > > but seems it returns allow sentences. > > Open a bugzilla. From dwalsh at redhat.com Tue Sep 29 11:57:31 2009 From: dwalsh at redhat.com (Daniel J Walsh) Date: Tue, 29 Sep 2009 07:57:31 -0400 Subject: have finally succeeded installing rawhide by livecd, got sealert but couldn't load it :( In-Reply-To: <4ABFB68B.80801@gmail.com> References: <604745.63142.qm@web52612.mail.re2.yahoo.com> <4ABFB68B.80801@gmail.com> Message-ID: <4AC1F62B.4060002@redhat.com> On 09/27/2009 03:01 PM, Justin P. Mattock wrote: > Antonio Olivares wrote: >> [liveuser at localhost ~]$ sealert >> Traceback (most recent call last): >> File "/usr/bin/sealert", line 37, in >> import slip.dbus.service >> File "/usr/lib/python2.6/site-packages/slip/dbus/__init__.py", line >> 1, in >> import bus >> ImportError: No module named bus >> [liveuser at localhost ~]$ dmesg | grep 'avc' >> type=1400 audit(1254092543.093:7): avc: denied { read } for pid=844 >> comm="passwd" path="/dev/console" dev=tmpfs ino=2114 >> scontext=system_u:system_r:passwd_t:s0 >> tcontext=system_u:object_r:console_device_t:s0 tclass=chr_file >> type=1400 audit(1254092543.094:8): avc: denied { read } for pid=844 >> comm="passwd" path="/dev/console" dev=tmpfs ino=2114 >> scontext=system_u:system_r:passwd_t:s0 >> tcontext=system_u:object_r:console_device_t:s0 tclass=chr_file >> >> installed from KDE-x86_64-20090926.19 >> >> [liveuser at localhost ~]$ uname -r >> 2.6.31.1-48.fc12.x86_64 >> [liveuser at localhost ~]$ cat /etc/fedora-release >> Fedora release 11.91 (Rawhide) >> >> >> Regards, >> >> Antonio >> >> >> >> >> -- >> fedora-selinux-list mailing list >> fedora-selinux-list at redhat.com >> https://www.redhat.com/mailman/listinfo/fedora-selinux-list >> >> > your missing a dbus module > I think it might be in the python-dbus > package. > > Justin P. Mattock > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list > > There was a bug in slip-dbus that is probably causing this problem. From mgrepl at redhat.com Tue Sep 29 12:08:53 2009 From: mgrepl at redhat.com (Miroslav Grepl) Date: Tue, 29 Sep 2009 14:08:53 +0200 Subject: Logging with bind-chroot In-Reply-To: <4AC1F506.1030800@redhat.com> References: <4ABB314D.5070209@city-fan.org> <4AC1F506.1030800@redhat.com> Message-ID: <4AC1F8D5.90603@redhat.com> On 09/29/2009 01:52 PM, Daniel J Walsh wrote: > On 09/24/2009 04:43 AM, Paul Howarth wrote: > >> Today's update of bind in F11 suggests adding this line to >> /etc/rsyslog.conf to maintain logging with a chroot-ed bind: >> >> $AddUnixListenSocket /var/named/chroot/dev/log >> >> For this to work on F-11, I needed to add the following policy module: >> >> :::::::::::::: >> mybindchroot.fc >> :::::::::::::: >> /var/named/chroot/dev -d gen_context(system_u:object_r:device_t,s0) >> /var/named/chroot/dev/log -s gen_context(system_u:object_r:devlog_t,s0) >> >> :::::::::::::: >> mybindchroot.te >> :::::::::::::: >> policy_module(mybindchroot, 0.0.4) >> >> require { >> type syslogd_t; >> } >> >> # rsyslog needs to search the bind chroot when creating >> # /dev/log in the chroot >> bind_search_cache(syslogd_t) >> >> I'd expect the same to apply in other releases too. >> >> Paul. >> >> -- >> fedora-selinux-list mailing list >> fedora-selinux-list at redhat.com >> https://www.redhat.com/mailman/listinfo/fedora-selinux-list >> >> >> > Added to Rawhide, > > Miroslav, you should add to F11. > > Added to selinux-policy-3.6.12-85.fc11 > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list > -------------- next part -------------- An HTML attachment was scrubbed... URL: From fedora03 at grifent.com Tue Sep 29 14:26:46 2009 From: fedora03 at grifent.com (John Griffiths) Date: Tue, 29 Sep 2009 10:26:46 -0400 Subject: Two AVCs In-Reply-To: <4AC1F34A.80000@redhat.com> References: <4ABA3516.9070106@grifent.com> <4ABA373F.2090709@redhat.com> <4ABA4612.9070800@grifent.com> <4AC1F34A.80000@redhat.com> Message-ID: <4AC21926.9090903@grifent.com> An HTML attachment was scrubbed... URL: From d.rye at roadtech.co.uk Tue Sep 29 17:53:21 2009 From: d.rye at roadtech.co.uk (J. David Rye of Roadtech) Date: Tue, 29 Sep 2009 18:53:21 +0100 Subject: Clamav/SeLinux, issue with system call recvmsg, and auxilary data. In-Reply-To: <20090928154931.GC10400@notebook3.grift.internal> References: <200909281622.19118.d.rye@roadtech.co.uk> <20090928154931.GC10400@notebook3.grift.internal> Message-ID: <200909291853.21205.d.rye@roadtech.co.uk> On Monday 28 September 2009 16:49, Dominick Grift wrote: > On Mon, Sep 28, 2009 at 04:22:18PM +0100, J. David Rye of Roadtech wrote: > > Hello All > > > > I triggered this issue with clamav/clamav-milter 0.95.2 from rpmforge > > running on a test box with Centos 5.3 > > > > Clamd opens a socket /var/run/clamav/clamd.sock to accept requests to > > scan things. > > > > ls -Z /var/run/clamav/clamd.sock > > srwxrwxrwx clamav clamav root:object_r:clamd_var_run_t > > /var/run/clamav/clamd.sock > > > > Requests are read using the system call recvmsg, this allows for the > > passing auxiliary control data. > > > > Clamav-milter 0.95.2 uses this to pass a handle to the temp file > > containing the data to be scanned > > > > With SeLinux set to targeted enforcing, this call reads and returns the > > normal data fine, but returns with the flag MSG_CTRUNC set. > > > > according to the man page this is > > "indicates that some control data were discarded due to lack of space in > > the buffer for ancillary data." > > > > clamd responded by closing the socket, clamav-milter responded to the > > closed socket by looping a 100% CPU. :-( > > > > > > Running the audit log through audit2allow suggests > > > > grep clam /var/log/audit/audit.log | audit2allow -m local > local.te > > [root at fallback0 selinux]# cat local.te > > > > module local 1.0; > > > > require { > > type initrc_tmp_t; > > type proc_t; > > type sysctl_kernel_t; > > type clamd_t; > > class dir search; > > class file { read write getattr }; > > } > > > > #============= clamd_t ============== > > allow clamd_t initrc_tmp_t:file { read write getattr }; > > allow clamd_t proc_t:file { read getattr }; > > allow clamd_t sysctl_kernel_t:dir search; > > allow clamd_t sysctl_kernel_t:file read; > > The first line means that something runs in the initrc_t init script > domain. Either the program executable file for this process is mislabeled > or there is no policy for this init daemon. > > ps auxZ | grep initrc_t > > The second and third / > fourth line signal that clamd_t needs read access to read_system_state > and read_sysctls. > > You could extend the clamd domain with a custom policy module to implement > this > > echo "policy_module(myclamd, 0.0.1)" >> myclamd.te; > echo "require { type clamd_t; }" > myclamd.te; > echo "kernel_read_system_state(clamd_t)" > myclamd.te; > echo "kernel_read_kernel_sysctls(clamd_t)" > myclamd.te; > > make -f /usr/share/selinux/devel/Makefile myclamd.pp > sudo semodule -i myclamd.pp > Thank you setsebool clamd_disable_trans=0 service clamd restart ls -Z /usr/sbin/clamav-milter /usr/sbin/clamd -rwxr-xr-x root root system_u:object_r:sbin_t /usr/sbin/clamav-milter -rwxr-xr-x root root system_u:object_r:clamd_exec_t /usr/sbin/clamd ps auxZ | egrep "initrc_t|clam" system_u:system_r:initrc_t nagios 2213 0.0 0.0 4968 948 ? Ss Sep23 0:12 nrpe -c /etc/nagios/nrpe.cfg -d system_u:system_r:initrc_t milter 2326 0.1 0.4 191796 4212 ? Ssl Sep23 13:26 /usr/local/sbin/milter-ahead root:system_r:clamd_t clamav 3227 1.1 7.4 88088 75092 ? Ssl 17:58 0:08 clamd root:system_r:unconfined_t:SystemLow-SystemHigh root 12979 0.0 0.0 3912 692 pts/0 R+ 18:10 0:00 egrep initrc_t|clam root:system_r:initrc_t clamav 20469 0.2 0.1 197700 1056 ? Ssl Sep25 12:29 clamav-milter --config-file=/etc/clamav-milter.conf cat myclamd. myclamd.fc myclamd.if myclamd.pp myclamd.te [root at fallback0 selinux]# cat myclamd.te policy_module(myclamd, 0.0.1) require { type clamd_t; } kernel_read_system_state(clamd_t) kernel_read_kernel_sysctls(clamd_t) make -f /usr/share/selinux/devel/Makefile myclamd.pp semodule -i myclamd.pp service clamd stop service clamav-milter stop /bin/rm /var/log/audit/audit* service auditd restart service clamd start service clamav-milter start # Now wait a bit grep clam /var/log/audit/audit.log | audit2allow -m local > local.te cat local.te module local 1.0; require { type initrc_tmp_t; type clamd_t; class file { read write }; } #============= clamd_t ============== grep clam /var/log/audit/audit.log | head type=AVC msg=audit(1254244568.860:58679): avc: denied { read write } for pid=14527 comm="clamd" path=2F746D702F636C616D61762D3538623532393261306361353666363733383634343663306531633261303834202864656C6574656429 dev=dm-0 ino=34668546 scontext=root:system_r:clamd_t:s0 tcontext=root:object_r:initrc_tmp_t:s0 tclass=file type=SYSCALL msg=audit(1254244568.860:58679): arch=40000003 syscall=102 success=yes exit=9 a0=11 a1=bfbe3610 a2=97763d4 a3=0 items=0 ppid=1 pid=14527 auid=0 uid=100 gid=101 euid=100 suid=100 fsuid=100 egid=101 sgid=101 fsgid=101 tty=(none) ses=2 comm="clamd" exe="/usr/sbin/clamd" subj=root:system_r:clamd_t:s0 key=(null) type=AVC msg=audit(1254244587.836:58680): avc: denied { read write } for pid=14527 comm="clamd" path=2F746D702F636C616D61762D3738373964653632626161306635396234646433626264613738376565363134202864656C6574656429 dev=dm-0 ino=34668546 scontext=root:system_r:clamd_t:s0 tcontext=root:object_r:initrc_tmp_t:s0 tclass=file type=SYSCALL msg=audit(1254244587.836:58680): arch=40000003 syscall=102 success=yes exit=9 a0=11 a1=bfbe3610 a2=97763d4 a3=0 items=0 ppid=1 pid=14527 auid=0 uid=100 gid=101 euid=100 suid=100 fsuid=100 egid=101 sgid=101 fsgid=101 tty=(none) ses=2 comm="clamd" exe="/usr/sbin/clamd" subj=root:system_r:clamd_t:s0 key=(null) type=AVC msg=audit(1254244625.080:58681): avc: denied { read write } for pid=14527 comm="clamd" path=2F746D702F636C616D61762D3838636236663661333332643165336262376563353861633537303764343966202864656C6574656429 dev=dm-0 ino=34668546 scontext=root:system_r:clamd_t:s0 tcontext=root:object_r:initrc_tmp_t:s0 tclass=file type=SYSCALL msg=audit(1254244625.080:58681): arch=40000003 syscall=102 success=yes exit=9 a0=11 a1=bfbe3610 a2=97763d4 a3=0 items=0 ppid=1 pid=14527 auid=0 uid=100 gid=101 euid=100 suid=100 fsuid=100 egid=101 sgid=101 fsgid=101 tty=(none) ses=2 comm="clamd" exe="/usr/sbin/clamd" subj=root:system_r:clamd_t:s0 key=(null) type=AVC msg=audit(1254244637.887:58682): avc: denied { read write } for pid=14527 comm="clamd" path=2F746D702F636C616D61762D3664613038663635306539396134396638376331363361373661323636633030202864656C6574656429 dev=dm-0 ino=34668546 scontext=root:system_r:clamd_t:s0 tcontext=root:object_r:initrc_tmp_t:s0 tclass=file type=SYSCALL msg=audit(1254244637.887:58682): arch=40000003 syscall=102 success=yes exit=9 a0=11 a1=bfbe3610 a2=97763d4 a3=0 items=0 ppid=1 pid=14527 auid=0 uid=100 gid=101 euid=100 suid=100 fsuid=100 egid=101 sgid=101 fsgid=101 tty=(none) ses=2 comm="clamd" exe="/usr/sbin/clamd" subj=root:system_r:clamd_t:s0 key=(null) type=AVC msg=audit(1254244638.164:58683): avc: denied { read write } for pid=14527 comm="clamd" path=2F746D702F636C616D61762D3830373639613532393465313533656333313966626638393963333863616231202864656C6574656429 dev=dm-0 ino=34668546 scontext=root:system_r:clamd_t:s0 tcontext=root:object_r:initrc_tmp_t:s0 tclass=file type=SYSCALL msg=audit(1254244638.164:58683): arch=40000003 syscall=102 success=yes exit=1 a0=11 a1=bfbe3610 a2=97763d4 a3=0 items=0 ppid=1 pid=14527 auid=0 uid=100 gid=101 euid=100 suid=100 fsuid=100 egid=101 sgid=101 fsgid=101 tty=(none) ses=2 comm="clamd" exe="/usr/sbin/clamd" subj=root:system_r:clamd_t:s0 key=(null) Which is that auxiliary data transfer with recvmsg failing on the socket the clamd created in the first place. ls -Z /var/run/clamav/clamd.sock srwxrwxrwx clamav clamav root:object_r:clamd_var_run_t /var/run/clamav/clamd.sock Why does the normal data stream through the socket work fine, but transferring file handles fail? > > The allow clamd_t proc_t:file { read getattr }; looks to relate to > > reading /proc/meminfo > > > > allow clamd_t sysctl_kernel_t:dir search; > > allow clamd_t sysctl_kernel_t:file read; > > Look to relate to these log entries > > type=AVC msg=audit(1254139856.343:48724): avc: denied { search } for > > pid=14771 comm="clamd" name="kernel" dev=proc ino=-268435416 > > scontext=root:system_r:clamd_t:s0 > > tcontext=system_u:object_r:sysctl_kernel_t:s0 tclass=dir type=AVC > > msg=audit(1254139856.343:48724): avc: denied { read } for pid=14771 > > comm="clamd" name="ngroups_max" dev=proc ino=-268435368 > > scontext=root:system_r:clamd_t:s0 > > tcontext=system_u:object_r:sysctl_kernel_t:s0 tclass=file type=AVC > > msg=audit(1254149740.665:48885): avc: denied { search } for pid=1261 > > comm="clamd" name="kernel" dev=proc ino=-268435416 > > scontext=root:system_r:clamd_t:s0 > > tcontext=system_u:object_r:sysctl_kernel_t:s0 tclass=dir > > > > This if I have figured it out right relate to something that clamd is > > calling in turn trying to read /proc/sys/kernel/ngroups_max > > > > > > So by elimination > > allow clamd_t initrc_tmp_t:file { read write getattr }; > > > > Must relate to the the use of auxiliary data with the socket, and the > > following log entries but I do not see why. Can anyone explain? > > > > type=AVC msg=audit(1254150147.188:48924): avc: denied { read write } > > for pid=1288 comm="clamd" > > path=2F746D702F636C616D61762D30636662376565326663316561396566363233643734 > >63316236626532623735202864656C6574656429 dev=dm-0 ino=34668546 > > scontext=root:system_r:clamd_t:s0 tcontext=root:object_r:initrc_tmp_t:s0 > > tclass=file type=AVC msg=audit(1254150153.681:48925): avc: denied { > > read write } for pid=1288 comm="clamd" > > path=2F746D702F636C616D61762D33363163323230333231386132396338653636336339 > >37303962663133363664202864656C6574656429 dev=dm-0 ino=34668546 > > scontext=root:system_r:clamd_t:s0 tcontext=root:object_r:initrc_tmp_t:s0 > > tclass=file type=AVC msg=audit(1254150177.903:48926): avc: denied { > > read write } for pid=1288 comm="clamd" > > path=2F746D702F636C616D61762D33666361626231386332376362313834666430646566 > >30643838353063363933202864656C6574656429 dev=dm-0 ino=34668546 > > scontext=root:system_r:clamd_t:s0 tcontext=root:object_r:initrc_tmp_t:s0 > > tclass=file type=AVC msg=audit(1254150188.366:48927): avc: denied { > > read write } for pid=1288 comm="clamd" > > path=2F746D702F636C616D61762D63663931316236323531303335643538326564353964 > >66663136373362626131202864656C6574656429 dev=dm-0 ino=34668546 > > scontext=root:system_r:clamd_t:s0 tcontext=root:object_r:initrc_tmp_t:s0 > > tclass=file type=AVC msg=audit(1254150220.428:48928): avc: denied { > > read write } for pid=1288 comm="clamd" > > path=2F746D702F636C616D61762D39316335346237613936306535313866303635396530 > >33363537303937323135202864656C6574656429 dev=dm-0 ino=34668546 > > scontext=root:system_r:clamd_t:s0 tcontext=root:object_r:initrc_tmp_t:s0 > > tclass=file > > > > > > Yours > > > > J. David Rye > > > > > > > > > > > > > > > > > > > > > > > > ************************************************************************* > > This e-mail is confidential and may be legally privileged. It is intended > > solely for the use of the individual(s) to whom it is addressed. Any > > content in this message is not necessarily a view or statement from Road > > Tech Computer Systems Limited but is that of the individual sender. If > > you are not the intended recipient, be advised that you have received > > this e-mail in error and that any use, dissemination, forwarding, > > printing, or copying of this e-mail is strictly prohibited. We use > > reasonable endeavours to virus scan all e-mails leaving the company but > > no warranty is given that this e-mail and any attachments are virus free. > > You should undertake your own virus checking. The right to monitor e-mail > > communications through our networks is reserved by us > > > > Road Tech Computer Systems Ltd. Shenley Hall, Rectory Lane, Shenley, > > Radlett, Hertfordshire, WD7 9AN. - VAT Registration No GB 449 3582 17 > > Registered in England No: 02017435, Registered Address: Charter Court, > > Midland Road, Hemel Hempstead, Hertfordshire, HP2 5GE. > > ************************************************************************* > > > > -- > > fedora-selinux-list mailing list > > fedora-selinux-list at redhat.com > > https://www.redhat.com/mailman/listinfo/fedora-selinux-list ************************************************************************* This e-mail is confidential and may be legally privileged. It is intended solely for the use of the individual(s) to whom it is addressed. Any content in this message is not necessarily a view or statement from Road Tech Computer Systems Limited but is that of the individual sender. If you are not the intended recipient, be advised that you have received this e-mail in error and that any use, dissemination, forwarding, printing, or copying of this e-mail is strictly prohibited. We use reasonable endeavours to virus scan all e-mails leaving the company but no warranty is given that this e-mail and any attachments are virus free. You should undertake your own virus checking. The right to monitor e-mail communications through our networks is reserved by us Road Tech Computer Systems Ltd. Shenley Hall, Rectory Lane, Shenley, Radlett, Hertfordshire, WD7 9AN. - VAT Registration No GB 449 3582 17 Registered in England No: 02017435, Registered Address: Charter Court, Midland Road, Hemel Hempstead, Hertfordshire, HP2 5GE. ************************************************************************* From domg472 at gmail.com Tue Sep 29 21:27:54 2009 From: domg472 at gmail.com (Dominick Grift) Date: Tue, 29 Sep 2009 23:27:54 +0200 Subject: Clamav/SeLinux, issue with system call recvmsg, and auxilary data. In-Reply-To: <200909291853.21205.d.rye@roadtech.co.uk> References: <200909281622.19118.d.rye@roadtech.co.uk> <20090928154931.GC10400@notebook3.grift.internal> <200909291853.21205.d.rye@roadtech.co.uk> Message-ID: <20090929212752.GA3068@notebook3.grift.internal> On Tue, Sep 29, 2009 at 06:53:21PM +0100, J. David Rye of Roadtech wrote: > > > On Monday 28 September 2009 16:49, Dominick Grift wrote: > > On Mon, Sep 28, 2009 at 04:22:18PM +0100, J. David Rye of Roadtech wrote: > > > Hello All > > > > > > I triggered this issue with clamav/clamav-milter 0.95.2 from rpmforge > > > running on a test box with Centos 5.3 > > > > > > Clamd opens a socket /var/run/clamav/clamd.sock to accept requests to > > > scan things. > > > > > > ls -Z /var/run/clamav/clamd.sock > > > srwxrwxrwx clamav clamav root:object_r:clamd_var_run_t > > > /var/run/clamav/clamd.sock > > > > > > Requests are read using the system call recvmsg, this allows for the > > > passing auxiliary control data. > > > > > > Clamav-milter 0.95.2 uses this to pass a handle to the temp file > > > containing the data to be scanned > > > > > > With SeLinux set to targeted enforcing, this call reads and returns the > > > normal data fine, but returns with the flag MSG_CTRUNC set. > > > > > > according to the man page this is > > > "indicates that some control data were discarded due to lack of space in > > > the buffer for ancillary data." > > > > > > clamd responded by closing the socket, clamav-milter responded to the > > > closed socket by looping a 100% CPU. :-( > > > > > > > > > Running the audit log through audit2allow suggests > > > > > > grep clam /var/log/audit/audit.log | audit2allow -m local > local.te > > > [root at fallback0 selinux]# cat local.te > > > > > > module local 1.0; > > > > > > require { > > > type initrc_tmp_t; > > > type proc_t; > > > type sysctl_kernel_t; > > > type clamd_t; > > > class dir search; > > > class file { read write getattr }; > > > } > > > > > > #============= clamd_t ============== > > > allow clamd_t initrc_tmp_t:file { read write getattr }; > > > allow clamd_t proc_t:file { read getattr }; > > > allow clamd_t sysctl_kernel_t:dir search; > > > allow clamd_t sysctl_kernel_t:file read; > > > > The first line means that something runs in the initrc_t init script > > domain. Either the program executable file for this process is mislabeled > > or there is no policy for this init daemon. > > > > ps auxZ | grep initrc_t > > > > The second and third / > > fourth line signal that clamd_t needs read access to read_system_state > > and read_sysctls. > > > > You could extend the clamd domain with a custom policy module to implement > > this > > > > echo "policy_module(myclamd, 0.0.1)" >> myclamd.te; > > echo "require { type clamd_t; }" > myclamd.te; > > echo "kernel_read_system_state(clamd_t)" > myclamd.te; > > echo "kernel_read_kernel_sysctls(clamd_t)" > myclamd.te; > > > > make -f /usr/share/selinux/devel/Makefile myclamd.pp > > sudo semodule -i myclamd.pp > > > Thank you > > setsebool clamd_disable_trans=0 > service clamd restart > ls -Z /usr/sbin/clamav-milter /usr/sbin/clamd > -rwxr-xr-x root root system_u:object_r:sbin_t /usr/sbin/clamav-milter > -rwxr-xr-x root root system_u:object_r:clamd_exec_t /usr/sbin/clamd > > ps auxZ | egrep "initrc_t|clam" > system_u:system_r:initrc_t nagios 2213 0.0 0.0 4968 948 ? Ss Sep23 0:12 nrpe -c /etc/nagios/nrpe.cfg -d > system_u:system_r:initrc_t milter 2326 0.1 0.4 191796 4212 ? Ssl Sep23 13:26 /usr/local/sbin/milter-ahead > root:system_r:clamd_t clamav 3227 1.1 7.4 88088 75092 ? Ssl 17:58 0:08 clamd > root:system_r:unconfined_t:SystemLow-SystemHigh root 12979 0.0 0.0 3912 692 pts/0 R+ 18:10 0:00 egrep initrc_t|clam > root:system_r:initrc_t clamav 20469 0.2 0.1 197700 1056 ? Ssl Sep25 12:29 clamav-milter --config-file=/etc/clamav-milter.conf My guess is that one of these create the initrc_tmp_t object. It would be best to get rid of all the initrc_t processes by writing policy for the milters and nagios initrc_t is a unconfined domain, a weak spot in your configuration. but as a temporary "as long as it works" fix you could run the avc denial throught audit2allow -M and load the module with semodule -i. until you fixed the core issue of your initrc_t processes. I might be able to help write policy for the milters but i would need a rpm -ql of the package and i wouldnt be able to test policy myself so youd have to test it and provide feedback. Might take a while.. myclamd. > myclamd.fc myclamd.if myclamd.pp myclamd.te > [root at fallback0 selinux]# cat myclamd.te > policy_module(myclamd, 0.0.1) > require { type clamd_t; } > kernel_read_system_state(clamd_t) > kernel_read_kernel_sysctls(clamd_t) > > make -f /usr/share/selinux/devel/Makefile myclamd.pp > semodule -i myclamd.pp > > service clamd stop > service clamav-milter stop > /bin/rm /var/log/audit/audit* > service auditd restart > service clamd start > service clamav-milter start > > # Now wait a bit > > grep clam /var/log/audit/audit.log | audit2allow -m local > local.te > > cat local.te > > module local 1.0; > > require { > type initrc_tmp_t; > type clamd_t; > class file { read write }; > } > > #============= clamd_t ============== > > grep clam /var/log/audit/audit.log | head > type=AVC msg=audit(1254244568.860:58679): avc: denied { read write } for pid=14527 comm="clamd" path=2F746D702F636C616D61762D3538623532393261306361353666363733383634343663306531633261303834202864656C6574656429 dev=dm-0 ino=34668546 scontext=root:system_r:clamd_t:s0 tcontext=root:object_r:initrc_tmp_t:s0 tclass=file > type=SYSCALL msg=audit(1254244568.860:58679): arch=40000003 syscall=102 success=yes exit=9 a0=11 a1=bfbe3610 a2=97763d4 a3=0 items=0 ppid=1 pid=14527 auid=0 uid=100 gid=101 euid=100 suid=100 fsuid=100 egid=101 sgid=101 fsgid=101 tty=(none) ses=2 comm="clamd" exe="/usr/sbin/clamd" subj=root:system_r:clamd_t:s0 key=(null) > type=AVC msg=audit(1254244587.836:58680): avc: denied { read write } for pid=14527 comm="clamd" path=2F746D702F636C616D61762D3738373964653632626161306635396234646433626264613738376565363134202864656C6574656429 dev=dm-0 ino=34668546 scontext=root:system_r:clamd_t:s0 tcontext=root:object_r:initrc_tmp_t:s0 tclass=file > type=SYSCALL msg=audit(1254244587.836:58680): arch=40000003 syscall=102 success=yes exit=9 a0=11 a1=bfbe3610 a2=97763d4 a3=0 items=0 ppid=1 pid=14527 auid=0 uid=100 gid=101 euid=100 suid=100 fsuid=100 egid=101 sgid=101 fsgid=101 tty=(none) ses=2 comm="clamd" exe="/usr/sbin/clamd" subj=root:system_r:clamd_t:s0 key=(null) > type=AVC msg=audit(1254244625.080:58681): avc: denied { read write } for pid=14527 comm="clamd" path=2F746D702F636C616D61762D3838636236663661333332643165336262376563353861633537303764343966202864656C6574656429 dev=dm-0 ino=34668546 scontext=root:system_r:clamd_t:s0 tcontext=root:object_r:initrc_tmp_t:s0 tclass=file > type=SYSCALL msg=audit(1254244625.080:58681): arch=40000003 syscall=102 success=yes exit=9 a0=11 a1=bfbe3610 a2=97763d4 a3=0 items=0 ppid=1 pid=14527 auid=0 uid=100 gid=101 euid=100 suid=100 fsuid=100 egid=101 sgid=101 fsgid=101 tty=(none) ses=2 comm="clamd" exe="/usr/sbin/clamd" subj=root:system_r:clamd_t:s0 key=(null) > type=AVC msg=audit(1254244637.887:58682): avc: denied { read write } for pid=14527 comm="clamd" path=2F746D702F636C616D61762D3664613038663635306539396134396638376331363361373661323636633030202864656C6574656429 dev=dm-0 ino=34668546 scontext=root:system_r:clamd_t:s0 tcontext=root:object_r:initrc_tmp_t:s0 tclass=file > type=SYSCALL msg=audit(1254244637.887:58682): arch=40000003 syscall=102 success=yes exit=9 a0=11 a1=bfbe3610 a2=97763d4 a3=0 items=0 ppid=1 pid=14527 auid=0 uid=100 gid=101 euid=100 suid=100 fsuid=100 egid=101 sgid=101 fsgid=101 tty=(none) ses=2 comm="clamd" exe="/usr/sbin/clamd" subj=root:system_r:clamd_t:s0 key=(null) > type=AVC msg=audit(1254244638.164:58683): avc: denied { read write } for pid=14527 comm="clamd" path=2F746D702F636C616D61762D3830373639613532393465313533656333313966626638393963333863616231202864656C6574656429 dev=dm-0 ino=34668546 scontext=root:system_r:clamd_t:s0 tcontext=root:object_r:initrc_tmp_t:s0 tclass=file > type=SYSCALL msg=audit(1254244638.164:58683): arch=40000003 syscall=102 success=yes exit=1 a0=11 a1=bfbe3610 a2=97763d4 a3=0 items=0 ppid=1 pid=14527 auid=0 uid=100 gid=101 euid=100 suid=100 fsuid=100 egid=101 sgid=101 fsgid=101 tty=(none) ses=2 comm="clamd" exe="/usr/sbin/clamd" subj=root:system_r:clamd_t:s0 key=(null) > > > Which is that auxiliary data transfer with recvmsg failing on the socket the clamd created in the first place. > ls -Z /var/run/clamav/clamd.sock > srwxrwxrwx clamav clamav root:object_r:clamd_var_run_t /var/run/clamav/clamd.sock > > Why does the normal data stream through the socket work fine, but transferring file handles fail? > > > > The allow clamd_t proc_t:file { read getattr }; looks to relate to > > > reading /proc/meminfo > > > > > > allow clamd_t sysctl_kernel_t:dir search; > > > allow clamd_t sysctl_kernel_t:file read; > > > Look to relate to these log entries > > > type=AVC msg=audit(1254139856.343:48724): avc: denied { search } for > > > pid=14771 comm="clamd" name="kernel" dev=proc ino=-268435416 > > > scontext=root:system_r:clamd_t:s0 > > > tcontext=system_u:object_r:sysctl_kernel_t:s0 tclass=dir type=AVC > > > msg=audit(1254139856.343:48724): avc: denied { read } for pid=14771 > > > comm="clamd" name="ngroups_max" dev=proc ino=-268435368 > > > scontext=root:system_r:clamd_t:s0 > > > tcontext=system_u:object_r:sysctl_kernel_t:s0 tclass=file type=AVC > > > msg=audit(1254149740.665:48885): avc: denied { search } for pid=1261 > > > comm="clamd" name="kernel" dev=proc ino=-268435416 > > > scontext=root:system_r:clamd_t:s0 > > > tcontext=system_u:object_r:sysctl_kernel_t:s0 tclass=dir > > > > > > This if I have figured it out right relate to something that clamd is > > > calling in turn trying to read /proc/sys/kernel/ngroups_max > > > > > > > > > So by elimination > > > allow clamd_t initrc_tmp_t:file { read write getattr }; > > > > > > Must relate to the the use of auxiliary data with the socket, and the > > > following log entries but I do not see why. Can anyone explain? > > > > > > type=AVC msg=audit(1254150147.188:48924): avc: denied { read write } > > > for pid=1288 comm="clamd" > > > path=2F746D702F636C616D61762D30636662376565326663316561396566363233643734 > > >63316236626532623735202864656C6574656429 dev=dm-0 ino=34668546 > > > scontext=root:system_r:clamd_t:s0 tcontext=root:object_r:initrc_tmp_t:s0 > > > tclass=file type=AVC msg=audit(1254150153.681:48925): avc: denied { > > > read write } for pid=1288 comm="clamd" > > > path=2F746D702F636C616D61762D33363163323230333231386132396338653636336339 > > >37303962663133363664202864656C6574656429 dev=dm-0 ino=34668546 > > > scontext=root:system_r:clamd_t:s0 tcontext=root:object_r:initrc_tmp_t:s0 > > > tclass=file type=AVC msg=audit(1254150177.903:48926): avc: denied { > > > read write } for pid=1288 comm="clamd" > > > path=2F746D702F636C616D61762D33666361626231386332376362313834666430646566 > > >30643838353063363933202864656C6574656429 dev=dm-0 ino=34668546 > > > scontext=root:system_r:clamd_t:s0 tcontext=root:object_r:initrc_tmp_t:s0 > > > tclass=file type=AVC msg=audit(1254150188.366:48927): avc: denied { > > > read write } for pid=1288 comm="clamd" > > > path=2F746D702F636C616D61762D63663931316236323531303335643538326564353964 > > >66663136373362626131202864656C6574656429 dev=dm-0 ino=34668546 > > > scontext=root:system_r:clamd_t:s0 tcontext=root:object_r:initrc_tmp_t:s0 > > > tclass=file type=AVC msg=audit(1254150220.428:48928): avc: denied { > > > read write } for pid=1288 comm="clamd" > > > path=2F746D702F636C616D61762D39316335346237613936306535313866303635396530 > > >33363537303937323135202864656C6574656429 dev=dm-0 ino=34668546 > > > scontext=root:system_r:clamd_t:s0 tcontext=root:object_r:initrc_tmp_t:s0 > > > tclass=file > > > > > > > > > Yours > > > > > > J. David Rye > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ************************************************************************* > > > This e-mail is confidential and may be legally privileged. It is intended > > > solely for the use of the individual(s) to whom it is addressed. Any > > > content in this message is not necessarily a view or statement from Road > > > Tech Computer Systems Limited but is that of the individual sender. If > > > you are not the intended recipient, be advised that you have received > > > this e-mail in error and that any use, dissemination, forwarding, > > > printing, or copying of this e-mail is strictly prohibited. We use > > > reasonable endeavours to virus scan all e-mails leaving the company but > > > no warranty is given that this e-mail and any attachments are virus free. > > > You should undertake your own virus checking. The right to monitor e-mail > > > communications through our networks is reserved by us > > > > > > Road Tech Computer Systems Ltd. Shenley Hall, Rectory Lane, Shenley, > > > Radlett, Hertfordshire, WD7 9AN. - VAT Registration No GB 449 3582 17 > > > Registered in England No: 02017435, Registered Address: Charter Court, > > > Midland Road, Hemel Hempstead, Hertfordshire, HP2 5GE. > > > ************************************************************************* > > > > > > -- > > > fedora-selinux-list mailing list > > > fedora-selinux-list at redhat.com > > > https://www.redhat.com/mailman/listinfo/fedora-selinux-list > > ************************************************************************* > This e-mail is confidential and may be legally privileged. It is intended > solely for the use of the individual(s) to whom it is addressed. Any > content in this message is not necessarily a view or statement from Road > Tech Computer Systems Limited but is that of the individual sender. If > you are not the intended recipient, be advised that you have received > this e-mail in error and that any use, dissemination, forwarding, > printing, or copying of this e-mail is strictly prohibited. We use > reasonable endeavours to virus scan all e-mails leaving the company but > no warranty is given that this e-mail and any attachments are virus free. > You should undertake your own virus checking. The right to monitor e-mail > communications through our networks is reserved by us > > Road Tech Computer Systems Ltd. Shenley Hall, Rectory Lane, Shenley, > Radlett, Hertfordshire, WD7 9AN. - VAT Registration No GB 449 3582 17 > Registered in England No: 02017435, Registered Address: Charter Court, > Midland Road, Hemel Hempstead, Hertfordshire, HP2 5GE. > ************************************************************************* > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From tony.molloy at ul.ie Wed Sep 30 09:15:14 2009 From: tony.molloy at ul.ie (Tony Molloy) Date: Wed, 30 Sep 2009 10:15:14 +0100 Subject: Samba AVC Message-ID: <200909301015.15335.tony.molloy@ul.ie> Hi, This is Centos 5.3 fully updated. Im getting the following error from setroubleshoot SELinux is preventing samba (smbd) "unlink" to ./log.cs244-34.old (samba_log_t). when samba tries to rotate the log files. Running sealert I get the following ( edited ) Summary: SELinux is preventing samba (smbd) "unlink" to ./log.cs244-24.old (samba_log_t). Detailed Description: SELinux denied samba access to ./log.cs244-24.old. If you want to share this directory with samba it has to have a file context label of samba_share_t. If ^^^^^^^^^^^^^ you did not intend to use ./log.cs244-24.old as a samba repository it could indicate either a bug or it could signal a intrusion attempt. Allowing Access: You can alter the file context by executing chcon -R -t samba_share_t './log.cs244-24.old' You must also change the default file context files on the system in order to preserve them even on a full relabel. "semanage fcontext -a -t samba_share_t './log.cs244-24.old'" The following command will allow this access: chcon -R -t samba_share_t './log.cs244-24.old' Additional Information: Source Context root:system_r:smbd_t Target Context root:object_r:samba_log_t Target Objects ./log.cs244-24.old [ file ] Source smbd Source Path /usr/sbin/smbd Port Host janus.x.y.z Source RPM Packages samba-3.0.33-3.7.el5_3.1 Target RPM Packages Policy RPM selinux-policy-2.4.6-203.el5 Selinux Enabled True Policy Type targeted MLS Enabled True Enforcing Mode Enforcing Plugin Name samba_share Host Name janus.x.y.z Platform Linux janus.x.y.z 2.6.18-128.7.1.el5 #1 SMP Mon Aug 24 08:21:56 EDT 2009 x86_64 x86_64 Alert Count 53 First Seen Fri Sep 25 15:54:24 2009 Last Seen Tue Sep 29 15:55:25 2009 Local ID e4426abc-3b0b-4df2-a380-3f0fba344c63 Line Numbers Raw Audit Messages host=janus.x.y.z type=AVC msg=audit(1254236125.438:70641): avc: denied { unlink } for pid=27420 comm="smbd" name="log.cs244-24.old" dev=sda5 ino=164076 scontext=root:system_r:smbd_t:s0 tcontext=root:object_r:samba_log_t:s0 tclass=file host=janus.x.y.z type=SYSCALL msg=audit(1254236125.438:70641): arch=c000003e syscall=82 success=no exit=-13 a0=2b1b457b5220 a1=7fffa9a7ba90 a2=1f a3=0 items=0 ppid=3787 pid=27420 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=1675 comm="smbd" exe="/usr/sbin/smbd" subj=root:system_r:smbd_t:s0 key=(null) log.cs244-24.old is a file not a directory and it's located in the /var/log/samba directory with permissions system_u:object_r:samba_log_t samba Any ideas, Tony -- Dept. of Comp. Sci. University of Limerick. From domg472 at gmail.com Wed Sep 30 11:18:17 2009 From: domg472 at gmail.com (Dominick Grift) Date: Wed, 30 Sep 2009 13:18:17 +0200 Subject: Samba AVC In-Reply-To: <200909301015.15335.tony.molloy@ul.ie> References: <200909301015.15335.tony.molloy@ul.ie> Message-ID: <20090930111816.GA3188@notebook3.grift.internal> On Wed, Sep 30, 2009 at 10:15:14AM +0100, Tony Molloy wrote: > > Hi, > > This is Centos 5.3 fully updated. > > Im getting the following error from setroubleshoot > > SELinux is preventing samba (smbd) "unlink" to ./log.cs244-34.old > (samba_log_t). > > when samba tries to rotate the log files. > > Running sealert I get the following ( edited ) > > Summary: > > SELinux is preventing samba (smbd) "unlink" to ./log.cs244-24.old > (samba_log_t). > > Detailed Description: > > SELinux denied samba access to ./log.cs244-24.old. If you want to share this > directory with samba it has to have a file context label of samba_share_t. If > ^^^^^^^^^^^^^ > you did not intend to use ./log.cs244-24.old as a samba repository it could > indicate either a bug or it could signal a intrusion attempt. > > Allowing Access: > > You can alter the file context by executing chcon -R -t samba_share_t > './log.cs244-24.old' You must also change the default file context files on > the > system in order to preserve them even on a full relabel. "semanage fcontext -a > -t samba_share_t './log.cs244-24.old'" > > The following command will allow this access: > > chcon -R -t samba_share_t './log.cs244-24.old' > > Additional Information: > > Source Context root:system_r:smbd_t > Target Context root:object_r:samba_log_t > Target Objects ./log.cs244-24.old [ file ] > Source smbd > Source Path /usr/sbin/smbd > Port > Host janus.x.y.z > Source RPM Packages samba-3.0.33-3.7.el5_3.1 > Target RPM Packages > Policy RPM selinux-policy-2.4.6-203.el5 > Selinux Enabled True > Policy Type targeted > MLS Enabled True > Enforcing Mode Enforcing > Plugin Name samba_share > Host Name janus.x.y.z > Platform Linux janus.x.y.z 2.6.18-128.7.1.el5 #1 SMP > Mon Aug 24 08:21:56 EDT 2009 x86_64 x86_64 > Alert Count 53 > First Seen Fri Sep 25 15:54:24 2009 > Last Seen Tue Sep 29 15:55:25 2009 > Local ID e4426abc-3b0b-4df2-a380-3f0fba344c63 > Line Numbers > > Raw Audit Messages > > host=janus.x.y.z type=AVC msg=audit(1254236125.438:70641): avc: denied { > unlink } for pid=27420 comm="smbd" name="log.cs244-24.old" dev=sda5 > ino=164076 scontext=root:system_r:smbd_t:s0 > tcontext=root:object_r:samba_log_t:s0 tclass=file > > host=janus.x.y.z type=SYSCALL msg=audit(1254236125.438:70641): arch=c000003e > syscall=82 success=no exit=-13 a0=2b1b457b5220 a1=7fffa9a7ba90 a2=1f a3=0 > items=0 ppid=3787 pid=27420 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 > sgid=0 fsgid=0 tty=(none) ses=1675 comm="smbd" exe="/usr/sbin/smbd" > subj=root:system_r:smbd_t:s0 key=(null) > > > log.cs244-24.old is a file not a directory and it's located in > the /var/log/samba directory with permissions > system_u:object_r:samba_log_t samba > > Any ideas, Looks like a valid bug in selinux-policy to me: echo "avc: denied { unlink } for pid=27420 comm="smbd" name="log.cs244-24.old" dev=sda5 ino=164076 scontext=root:system_r:smbd_t:s0 tcontext=root:object_r:samba_log_t:s0 tclass=file" | audit2allow -M mysmbd; /usr/sbin/semodule -i mysmbd.pp Should grant this particular access vector. > > Tony > > -- > > Dept. of Comp. Sci. > University of Limerick. > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From shintaro.fujiwara at gmail.com Wed Sep 30 11:26:51 2009 From: shintaro.fujiwara at gmail.com (Shintaro Fujiwara) Date: Wed, 30 Sep 2009 20:26:51 +0900 Subject: sesearch --neverallow is broken ? In-Reply-To: <4AC1F5F5.8000700@redhat.com> References: <4AC1F5F5.8000700@redhat.com> Message-ID: 2009/9/29 Daniel J Walsh : > On 09/26/2009 11:18 PM, Shintaro Fujiwara wrote: >> I typed in F11, >> >> sesearch --neverallow >> >> but seems it returns allow sentences. >> >> > Open a bugzilla. Yes, but which component should I post, checkpolicy or policycoreutils or selinux-policy or selinux-policy-targeted or ...? > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list > -- http://intrajp.no-ip.com/ Home Page From domg472 at gmail.com Wed Sep 30 11:31:35 2009 From: domg472 at gmail.com (Dominick Grift) Date: Wed, 30 Sep 2009 13:31:35 +0200 Subject: sesearch --neverallow is broken ? In-Reply-To: References: <4AC1F5F5.8000700@redhat.com> Message-ID: <20090930113134.GB3188@notebook3.grift.internal> On Wed, Sep 30, 2009 at 08:26:51PM +0900, Shintaro Fujiwara wrote: > 2009/9/29 Daniel J Walsh : > > On 09/26/2009 11:18 PM, Shintaro Fujiwara wrote: > >> I typed in F11, > >> > >> sesearch --neverallow > >> > >> but seems it returns allow sentences. > >> > >> > > Open a bugzilla. > > Yes, but which component should I post, checkpolicy or policycoreutils > or selinux-policy or selinux-policy-targeted or ...? setools i believe > > > > -- > > fedora-selinux-list mailing list > > fedora-selinux-list at redhat.com > > https://www.redhat.com/mailman/listinfo/fedora-selinux-list > > > > > > -- > http://intrajp.no-ip.com/ Home Page > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From tony.molloy at ul.ie Wed Sep 30 12:17:30 2009 From: tony.molloy at ul.ie (Tony Molloy) Date: Wed, 30 Sep 2009 13:17:30 +0100 Subject: Samba AVC In-Reply-To: <20090930111816.GA3188@notebook3.grift.internal> References: <200909301015.15335.tony.molloy@ul.ie> <20090930111816.GA3188@notebook3.grift.internal> Message-ID: <200909301317.31362.tony.molloy@ul.ie> On Wednesday 30 September 2009 12:18:17 Dominick Grift wrote: > On Wed, Sep 30, 2009 at 10:15:14AM +0100, Tony Molloy wrote: > > Hi, > > > > This is Centos 5.3 fully updated. > > > > Im getting the following error from setroubleshoot > > > > SELinux is preventing samba (smbd) "unlink" to ./log.cs244-34.old > > (samba_log_t). > > > > when samba tries to rotate the log files. > > > > Running sealert I get the following ( edited ) > > > > Summary: > > > > SELinux is preventing samba (smbd) "unlink" to ./log.cs244-24.old > > (samba_log_t). > > > > Detailed Description: > > > > SELinux denied samba access to ./log.cs244-24.old. If you want to share > > this directory with samba it has to have a file context label of > > samba_share_t. If ^^^^^^^^^^^^^ > > you did not intend to use ./log.cs244-24.old as a samba repository it > > could indicate either a bug or it could signal a intrusion attempt. > > > > Allowing Access: > > > > You can alter the file context by executing chcon -R -t samba_share_t > > './log.cs244-24.old' You must also change the default file context files > > on the > > system in order to preserve them even on a full relabel. "semanage > > fcontext -a -t samba_share_t './log.cs244-24.old'" > > > > The following command will allow this access: > > > > chcon -R -t samba_share_t './log.cs244-24.old' > > > > Additional Information: > > > > Source Context root:system_r:smbd_t > > Target Context root:object_r:samba_log_t > > Target Objects ./log.cs244-24.old [ file ] > > Source smbd > > Source Path /usr/sbin/smbd > > Port > > Host janus.x.y.z > > Source RPM Packages samba-3.0.33-3.7.el5_3.1 > > Target RPM Packages > > Policy RPM selinux-policy-2.4.6-203.el5 > > Selinux Enabled True > > Policy Type targeted > > MLS Enabled True > > Enforcing Mode Enforcing > > Plugin Name samba_share > > Host Name janus.x.y.z > > Platform Linux janus.x.y.z 2.6.18-128.7.1.el5 #1 SMP > > Mon Aug 24 08:21:56 EDT 2009 x86_64 x86_64 > > Alert Count 53 > > First Seen Fri Sep 25 15:54:24 2009 > > Last Seen Tue Sep 29 15:55:25 2009 > > Local ID e4426abc-3b0b-4df2-a380-3f0fba344c63 > > Line Numbers > > > > Raw Audit Messages > > > > host=janus.x.y.z type=AVC msg=audit(1254236125.438:70641): avc: denied > > { unlink } for pid=27420 comm="smbd" name="log.cs244-24.old" dev=sda5 > > ino=164076 scontext=root:system_r:smbd_t:s0 > > tcontext=root:object_r:samba_log_t:s0 tclass=file > > > > host=janus.x.y.z type=SYSCALL msg=audit(1254236125.438:70641): > > arch=c000003e syscall=82 success=no exit=-13 a0=2b1b457b5220 > > a1=7fffa9a7ba90 a2=1f a3=0 items=0 ppid=3787 pid=27420 auid=0 uid=0 gid=0 > > euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=1675 > > comm="smbd" exe="/usr/sbin/smbd" subj=root:system_r:smbd_t:s0 key=(null) > > > > > > log.cs244-24.old is a file not a directory and it's located in > > the /var/log/samba directory with permissions > > system_u:object_r:samba_log_t samba > > > > Any ideas, > > Looks like a valid bug in selinux-policy to me: > > echo "avc: denied { > unlink } for pid=27420 comm="smbd" name="log.cs244-24.old" dev=sda5 > ino=164076 scontext=root:system_r:smbd_t:s0 > tcontext=root:object_r:samba_log_t:s0 tclass=file" | audit2allow -M mysmbd; > /usr/sbin/semodule -i mysmbd.pp > > Should grant this particular access vector. > Thanks I generated local policy to allow it. Regards, Tony > > Tony > > > > -- > > > > Dept. of Comp. Sci. > > University of Limerick. > > > > -- > > fedora-selinux-list mailing list > > fedora-selinux-list at redhat.com > > https://www.redhat.com/mailman/listinfo/fedora-selinux-list -- Dept. of Comp. Sci. University of Limerick. From yersinia.spiros at gmail.com Wed Sep 30 12:37:22 2009 From: yersinia.spiros at gmail.com (yersinia) Date: Wed, 30 Sep 2009 14:37:22 +0200 Subject: Samba AVC In-Reply-To: <200909301317.31362.tony.molloy@ul.ie> References: <200909301015.15335.tony.molloy@ul.ie> <20090930111816.GA3188@notebook3.grift.internal> <200909301317.31362.tony.molloy@ul.ie> Message-ID: On Wed, Sep 30, 2009 at 2:17 PM, Tony Molloy wrote: > On Wednesday 30 September 2009 12:18:17 Dominick Grift wrote: > > On Wed, Sep 30, 2009 at 10:15:14AM +0100, Tony Molloy wrote: > > > Hi, > > > > > > This is Centos 5.3 fully updated. > > > > > > Im getting the following error from setroubleshoot > > > > > > SELinux is preventing samba (smbd) "unlink" to ./log.cs244-34.old > > > (samba_log_t). > > > > > > when samba tries to rotate the log files. > > > > > > Running sealert I get the following ( edited ) > > > > > > Summary: > > > > > > SELinux is preventing samba (smbd) "unlink" to ./log.cs244-24.old > > > (samba_log_t). > > > > > > Detailed Description: > > > > > > SELinux denied samba access to ./log.cs244-24.old. If you want to share > > > this directory with samba it has to have a file context label of > > > samba_share_t. If ^^^^^^^^^^^^^ > > > you did not intend to use ./log.cs244-24.old as a samba repository it > > > could indicate either a bug or it could signal a intrusion attempt. > > > > > > Allowing Access: > > > > > > You can alter the file context by executing chcon -R -t samba_share_t > > > './log.cs244-24.old' You must also change the default file context > files > > > on the > > > system in order to preserve them even on a full relabel. "semanage > > > fcontext -a -t samba_share_t './log.cs244-24.old'" > > > > > > The following command will allow this access: > > > > > > chcon -R -t samba_share_t './log.cs244-24.old' > > > > > > Additional Information: > > > > > > Source Context root:system_r:smbd_t > > > Target Context root:object_r:samba_log_t > > > Target Objects ./log.cs244-24.old [ file ] > > > Source smbd > > > Source Path /usr/sbin/smbd > > > Port > > > Host janus.x.y.z > > > Source RPM Packages samba-3.0.33-3.7.el5_3.1 > > > Target RPM Packages > > > Policy RPM selinux-policy-2.4.6-203.el5 > > > Selinux Enabled True > > > Policy Type targeted > > > MLS Enabled True > > > Enforcing Mode Enforcing > > > Plugin Name samba_share > > > Host Name janus.x.y.z > > > Platform Linux janus.x.y.z 2.6.18-128.7.1.el5 #1 > SMP > > > Mon Aug 24 08:21:56 EDT 2009 x86_64 > x86_64 > > > Alert Count 53 > > > First Seen Fri Sep 25 15:54:24 2009 > > > Last Seen Tue Sep 29 15:55:25 2009 > > > Local ID e4426abc-3b0b-4df2-a380-3f0fba344c63 > > > Line Numbers > > > > > > Raw Audit Messages > > > > > > host=janus.x.y.z type=AVC msg=audit(1254236125.438:70641): avc: denied > > > { unlink } for pid=27420 comm="smbd" name="log.cs244-24.old" dev=sda5 > > > ino=164076 scontext=root:system_r:smbd_t:s0 > > > tcontext=root:object_r:samba_log_t:s0 tclass=file > > > > > > host=janus.x.y.z type=SYSCALL msg=audit(1254236125.438:70641): > > > arch=c000003e syscall=82 success=no exit=-13 a0=2b1b457b5220 > > > a1=7fffa9a7ba90 a2=1f a3=0 items=0 ppid=3787 pid=27420 auid=0 uid=0 > gid=0 > > > euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=1675 > > > comm="smbd" exe="/usr/sbin/smbd" subj=root:system_r:smbd_t:s0 > key=(null) > > > > > > > > > log.cs244-24.old is a file not a directory and it's located in > > > the /var/log/samba directory with permissions > > > system_u:object_r:samba_log_t samba > > > > > > Any ideas, > > > > Looks like a valid bug in selinux-policy to me: > > > > echo "avc: denied { > > unlink } for pid=27420 comm="smbd" name="log.cs244-24.old" dev=sda5 > > ino=164076 scontext=root:system_r:smbd_t:s0 > > tcontext=root:object_r:samba_log_t:s0 tclass=file" | audit2allow -M > mysmbd; > > /usr/sbin/semodule -i mysmbd.pp > > > > Should grant this particular access vector. > > > > Thanks I generated local policy to allow it. > > In origin what is the result of this. In my system sesearch -s smbd_t -c file --allow | grep samba_log_t allow smbd_t samba_log_t : file { ioctl read write create getattr setattr lock append unlink link rename }; allow smbd_t samba_log_t : file { ioctl read getattr lock }; allow smbd_t samba_log_t : file { ioctl read write create getattr setattr lock append unlink link rename }; Because i have no problem and in fact unlink is allowed. Are you sure to have selinux-policy-targeted installed ? Regards > Regards, > > Tony > > > Tony > > > > > > -- > > > > > > Dept. of Comp. Sci. > > > University of Limerick. > > > > > > -- > > > fedora-selinux-list mailing list > > > fedora-selinux-list at redhat.com > > > https://www.redhat.com/mailman/listinfo/fedora-selinux-list > > > > -- > > Dept. of Comp. Sci. > University of Limerick. > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dwalsh at redhat.com Wed Sep 30 17:32:21 2009 From: dwalsh at redhat.com (Daniel J Walsh) Date: Wed, 30 Sep 2009 13:32:21 -0400 Subject: Samba AVC In-Reply-To: References: <200909301015.15335.tony.molloy@ul.ie> <20090930111816.GA3188@notebook3.grift.internal> <200909301317.31362.tony.molloy@ul.ie> Message-ID: <4AC39625.8090703@redhat.com> On 09/30/2009 08:37 AM, yersinia wrote: > On Wed, Sep 30, 2009 at 2:17 PM, Tony Molloy wrote: > >> On Wednesday 30 September 2009 12:18:17 Dominick Grift wrote: >>> On Wed, Sep 30, 2009 at 10:15:14AM +0100, Tony Molloy wrote: >>>> Hi, >>>> >>>> This is Centos 5.3 fully updated. >>>> >>>> Im getting the following error from setroubleshoot >>>> >>>> SELinux is preventing samba (smbd) "unlink" to ./log.cs244-34.old >>>> (samba_log_t). >>>> >>>> when samba tries to rotate the log files. >>>> >>>> Running sealert I get the following ( edited ) >>>> >>>> Summary: >>>> >>>> SELinux is preventing samba (smbd) "unlink" to ./log.cs244-24.old >>>> (samba_log_t). >>>> >>>> Detailed Description: >>>> >>>> SELinux denied samba access to ./log.cs244-24.old. If you want to share >>>> this directory with samba it has to have a file context label of >>>> samba_share_t. If ^^^^^^^^^^^^^ >>>> you did not intend to use ./log.cs244-24.old as a samba repository it >>>> could indicate either a bug or it could signal a intrusion attempt. >>>> >>>> Allowing Access: >>>> >>>> You can alter the file context by executing chcon -R -t samba_share_t >>>> './log.cs244-24.old' You must also change the default file context >> files >>>> on the >>>> system in order to preserve them even on a full relabel. "semanage >>>> fcontext -a -t samba_share_t './log.cs244-24.old'" >>>> >>>> The following command will allow this access: >>>> >>>> chcon -R -t samba_share_t './log.cs244-24.old' >>>> >>>> Additional Information: >>>> >>>> Source Context root:system_r:smbd_t >>>> Target Context root:object_r:samba_log_t >>>> Target Objects ./log.cs244-24.old [ file ] >>>> Source smbd >>>> Source Path /usr/sbin/smbd >>>> Port >>>> Host janus.x.y.z >>>> Source RPM Packages samba-3.0.33-3.7.el5_3.1 >>>> Target RPM Packages >>>> Policy RPM selinux-policy-2.4.6-203.el5 >>>> Selinux Enabled True >>>> Policy Type targeted >>>> MLS Enabled True >>>> Enforcing Mode Enforcing >>>> Plugin Name samba_share >>>> Host Name janus.x.y.z >>>> Platform Linux janus.x.y.z 2.6.18-128.7.1.el5 #1 >> SMP >>>> Mon Aug 24 08:21:56 EDT 2009 x86_64 >> x86_64 >>>> Alert Count 53 >>>> First Seen Fri Sep 25 15:54:24 2009 >>>> Last Seen Tue Sep 29 15:55:25 2009 >>>> Local ID e4426abc-3b0b-4df2-a380-3f0fba344c63 >>>> Line Numbers >>>> >>>> Raw Audit Messages >>>> >>>> host=janus.x.y.z type=AVC msg=audit(1254236125.438:70641): avc: denied >>>> { unlink } for pid=27420 comm="smbd" name="log.cs244-24.old" dev=sda5 >>>> ino=164076 scontext=root:system_r:smbd_t:s0 >>>> tcontext=root:object_r:samba_log_t:s0 tclass=file >>>> >>>> host=janus.x.y.z type=SYSCALL msg=audit(1254236125.438:70641): >>>> arch=c000003e syscall=82 success=no exit=-13 a0=2b1b457b5220 >>>> a1=7fffa9a7ba90 a2=1f a3=0 items=0 ppid=3787 pid=27420 auid=0 uid=0 >> gid=0 >>>> euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=1675 >>>> comm="smbd" exe="/usr/sbin/smbd" subj=root:system_r:smbd_t:s0 >> key=(null) >>>> >>>> >>>> log.cs244-24.old is a file not a directory and it's located in >>>> the /var/log/samba directory with permissions >>>> system_u:object_r:samba_log_t samba >>>> >>>> Any ideas, >>> >>> Looks like a valid bug in selinux-policy to me: >>> >>> echo "avc: denied { >>> unlink } for pid=27420 comm="smbd" name="log.cs244-24.old" dev=sda5 >>> ino=164076 scontext=root:system_r:smbd_t:s0 >>> tcontext=root:object_r:samba_log_t:s0 tclass=file" | audit2allow -M >> mysmbd; >>> /usr/sbin/semodule -i mysmbd.pp >>> >>> Should grant this particular access vector. >>> >> >> Thanks I generated local policy to allow it. >> >> In origin what is the result of this. In my system > > sesearch -s smbd_t -c file --allow | grep samba_log_t > allow smbd_t samba_log_t : file { ioctl read write create getattr setattr > lock append unlink link rename }; > allow smbd_t samba_log_t : file { ioctl read getattr lock }; > allow smbd_t samba_log_t : file { ioctl read write create getattr setattr > lock append unlink link rename }; > > Because i have no problem and in fact unlink is allowed. > > Are you sure to have selinux-policy-targeted installed ? > > Regards > > >> Regards, >> >> Tony >>>> Tony >>>> >>>> -- >>>> >>>> Dept. of Comp. Sci. >>>> University of Limerick. >>>> >>>> -- >>>> fedora-selinux-list mailing list >>>> fedora-selinux-list at redhat.com >>>> https://www.redhat.com/mailman/listinfo/fedora-selinux-list >> >> >> >> -- >> >> Dept. of Comp. Sci. >> University of Limerick. >> >> -- >> fedora-selinux-list mailing list >> fedora-selinux-list at redhat.com >> https://www.redhat.com/mailman/listinfo/fedora-selinux-list >> > > > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list This is definitely fixed in 5.4 policy. 5.5 policy is now previewing at http://people.redhat.com/dwalsh/SELinux/RHEL5 From shintaro.fujiwara at gmail.com Wed Sep 30 18:32:36 2009 From: shintaro.fujiwara at gmail.com (Shintaro Fujiwara) Date: Thu, 1 Oct 2009 03:32:36 +0900 Subject: sesearch --neverallow is broken ? In-Reply-To: <20090930113134.GB3188@notebook3.grift.internal> References: <4AC1F5F5.8000700@redhat.com> <20090930113134.GB3188@notebook3.grift.internal> Message-ID: 2009/9/30 Dominick Grift : > On Wed, Sep 30, 2009 at 08:26:51PM +0900, Shintaro Fujiwara wrote: >> 2009/9/29 Daniel J Walsh : >> > On 09/26/2009 11:18 PM, Shintaro Fujiwara wrote: >> >> I typed in F11, >> >> >> >> sesearch --neverallow >> >> >> >> but seems it returns allow sentences. >> >> >> >> >> > Open a bugzilla. >> >> Yes, but which component should I post, checkpolicy or policycoreutils >> or selinux-policy or selinux-policy-targeted or ...? > > setools i believe >> > Thanks I opend a bugzilla. https://bugzilla.redhat.com/show_bug.cgi?id=526460 >> > -- >> > fedora-selinux-list mailing list >> > fedora-selinux-list at redhat.com >> > https://www.redhat.com/mailman/listinfo/fedora-selinux-list >> > >> >> >> >> -- >> http://intrajp.no-ip.com/ Home Page >> >> -- >> fedora-selinux-list mailing list >> fedora-selinux-list at redhat.com >> https://www.redhat.com/mailman/listinfo/fedora-selinux-list > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list > -- http://intrajp.no-ip.com/ Home Page