selinux November 2007

selinux@lists.fedoraproject.org

40 participants
53 discussions

Memory protection and system-config-securitylevel
by Kamil J. Dudek 28 Sep '09

28 Sep '09

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... 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 -- Pozdrawiam - Kamil J. Dudek

2 3

mount point labels
by Clarkson, Mike R (US SSA) 14 Sep '09

14 Sep '09

I'm attempting to create the labeled mount point with the following command: mount -t nfs -o context=system_u:object_r:import_file_t:s0 nas:/vol/home /home/SimulatedImport/output/home The mount point is created without any errors, but the label that I specify in the mount command is not used. Instead of system_u:object_r:import_file_t, the context of the /home/SimulatedImport/output/home is system_u:object_r:nfs_t:s0. ls -dZ /home/SimulatedImport/output/home drwxr-xr-x root root system_u:object_r:nfs_t:s0 /home/m252/SimulatedImport/output/home I'm running RHEL5 with a policy built as mls off of the targeted policy. Does anyone know why the context label is not taking? Thanks

3 7

xinetd rsync --daemon problems
by Chuck Anderson 03 Jul '08

03 Jul '08

I'm using Fedora Core 6, and trying to start a rsync daemon via xinetd. The default configuration is: # default: off # description: The rsync server is a good addition to an ftp server, as it \ # allows crc checksumming etc. service rsync { disable = no socket_type = stream wait = no user = root server = /usr/bin/rsync server_args = --daemon log_on_failure += USERID } With this rsyncd.conf: motd file = /etc/rsyncd.motd pid file = /var/run/rsyncd.pid port = 873 uid = rsyncd gid = mirror use chroot = yes max connections = 10 log file = /var/log/rsyncd.log read only = yes hosts allow = 127.0.0.1, ::1, etc.... #hosts deny = 0.0.0.0/0, :: ignore nonreadable = yes transfer logging = yes timeout = 600 dont compress = * [fedora-linux-core] path = /srv/ftp/pub/fedora/linux/core comment = Fedora Linux Core [fedora-linux-core-updates] path = /srv/ftp/pub/fedora/linux/core/updates comment = Fedora Linux Core Updates [fedora-linux-extras] path = /srv/ftp/pub/fedora/linux/extras comment = Fedora Linux Extras [fedora-linux-core-test] path = /srv/ftp/pub/fedora/linux/core/test comment = Fedora Linux Core Test [fedora-linux-releases] path = /srv/ftp/pub/fedora/linux/releases comment = Fedora Linux Releases [fedora-linux-development] path = /srv/ftp/pub/fedora/linux/development comment = Fedora Linux Development [fedora-enchilada] path = /srv/ftp/pub/fedora comment = Fedora - The whole enchilada [fedora-linux-updates] path = /srv/ftp/pub/fedora/linux/updates comment = Fedora Linux Updates [fedora-web] path = /srv/ftp/pub/fedora/web comment = Web content for Fedora Linux mirrors I get these AVCs when running from xinetd and making a client connection that I don't get if I start the daemon directly via "rsync --daemon" as root: type=AVC msg=audit(1192132336.713:3464): avc: denied { lock } for pid=8488 comm="rsync" name="rsyncd.lock" dev=dm-4 ino=2064435 scontext=user_u:system_r:rsync_t:s0 tcontext=root:object_r:var_run_t:s0 tclass=file type=SYSCALL msg=audit(1192132336.713:3464): arch=40000003 syscall=221 success=no exit=-13 a0=4 a1=d a2=bff80730 a3=bff80730 items=0 ppid=8167 pid=8488 auid=10002 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) comm="rsync" exe="/usr/bin/rsync" subj=user_u:system_r:rsync_t:s0 key=(null) type=AVC_PATH msg=audit(1192132336.713:3464): path="/var/run/rsyncd.lock" type=AVC msg=audit(1192132400.044:3465): avc: denied { bind } for pid=8499 comm="rsync" scontext=user_u:system_r:rsync_t:s0 tcontext=user_u:system_r:rsync_t:s0 tclass=netlink_route_socket type=SYSCALL msg=audit(1192132400.044:3465): arch=40000003 syscall=102 success=no exit=-13 a0=2 a1=bf8f4674 a2=4df50ff4 a3=3 items=0 ppid=8167 pid=8499 auid=10002 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) comm="rsync" exe="/usr/bin/rsync" subj=user_u:system_r:rsync_t:s0 key=(null) I tried creating and loading a policy module: # grep "rsync" /var/log/audit/audit.log | audit2allow -M rsyncd # semodule -i rsyncd.pp Here is rsyncd.te: module rsyncd 1.0; require { type var_run_t; type rsync_t; class netlink_route_socket create; class file { read write }; } #============= rsync_t ============== allow rsync_t self:netlink_route_socket create; allow rsync_t var_run_t:file { read write }; But I still get these AVCs: type=AVC msg=audit(1192139751.238:3586): avc: denied { bind } for pid=9311 comm="rsync" scontext=user_u:system_r:rsync_t:s0 tcontext=user_u:system_r:rsync_t:s0 tclass=netlink_route_socket type=SYSCALL msg=audit(1192139751.238:3586): arch=40000003 syscall=102 success=no exit=-13 a0=2 a1=bfbb6144 a2=4df50ff4 a3=3 items=0 ppid=8732 pid=9311 auid=10002 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) comm="rsync" exe="/usr/bin/rsync" subj=user_u:system_r:rsync_t:s0 key=(null) Additionally, when using xinetd I don't ever get any log messages in /var/log/rsyncd.log like I do when I run "rsync --daemon" directly: 2007/10/11 17:08:01 [8613] rsyncd version 2.6.9 starting, listening on port 873 2007/10/11 17:08:13 [8616] connect from dustpuppy.wpi.edu (2001:468:616:8c9:213:72ff:fe74:da15) 2007/10/11 17:08:13 [8616] rsync on fedora-enchilada/linux/ from dustpuppy.wpi.edu (2001:468:616:8c9:213:72ff:fe74:da15) 2007/10/11 21:08:13 [8616] building file list 2007/10/11 21:08:13 [8616] sent 1629 bytes received 106 bytes total size 19

2 2

gdm + selinux problem
by Dr. Michael J. Chudobiak 31 Dec '07

31 Dec '07

Hi all, After an F7 -> F8 upgrade, I can't start the xorg server in enforcing mode. Logs say things like: type=AVC msg=audit(1195824979.681:23): avc: denied { getattr } for pid=2585 comm="gdm-binary" path="/tmp/.X11-unix" dev=dm-0 ino=8871462 scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tcontext=system_u:object_r:initrc_tmp_t:s0 tclass=dir type=SYSCALL msg=audit(1195824979.681:23): arch=40000003 syscall=196 success=yes exit=0 a0=8090daf a1=bfb4d320 a2=c2bff4 a3=3 items=0 ppid=1 pid=2585 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) comm="gdm-binary" exe="/usr/sbin/gdm-binary" subj=system_u:system_r:xdm_t:s0-s0:c0.c1023 key=(null) audit2allow says: #============= cupsd_t ============== allow cupsd_t nscd_t:nscd shmemserv; #============= iptables_t ============== allow iptables_t nscd_t:nscd shmemserv; #============= nfsd_t ============== allow nfsd_t nscd_t:nscd { shmemserv getserv }; #============= ntpd_t ============== allow ntpd_t nscd_t:nscd shmemserv; #============= sendmail_t ============== allow sendmail_t fail2ban_log_t:file append; allow sendmail_t initrc_t:unix_stream_socket { read write }; allow sendmail_t nscd_t:nscd shmemserv; #============= system_mail_t ============== allow system_mail_t nscd_t:nscd shmemserv; #============= xdm_t ============== allow xdm_t initrc_tmp_t:dir { getattr setattr }; #============= xdm_xserver_t ============== allow xdm_xserver_t initrc_tmp_t:dir { write getattr search add_name }; allow xdm_xserver_t initrc_tmp_t:sock_file create; Now... how would this have happened? Should I just run the above commands to fix everything, or is there a deeper bug / issue? Help appreciated! - Mike

2 3

[Bug] about the bug with semanage
by NZzi 05 Dec '07

05 Dec '07

hi selinuxers: several days, i remmeber someone report a bug about semanage in non-english locale: -(:11:30:$)-> locale LANG=zh_CN.UTF-8 LC_CTYPE="zh_CN.UTF-8" LC_NUMERIC="zh_CN.UTF-8" LC_TIME="zh_CN.UTF-8" LC_COLLATE="zh_CN.UTF-8" LC_MONETARY="zh_CN.UTF-8" LC_MESSAGES="zh_CN.UTF-8" LC_PAPER="zh_CN.UTF-8" LC_NAME="zh_CN.UTF-8" LC_ADDRESS="zh_CN.UTF-8" LC_TELEPHONE="zh_CN.UTF-8" LC_MEASUREMENT="zh_CN.UTF-8" LC_IDENTIFICATION="zh_CN.UTF-8" LC_ALL= -(yangshao@NZzi:pts/4)--------------------(~)-(3/133)- -(:13:17:$)-> sudo semanage login -l /usr/sbin/semanage: ascii -(:11:02:$)-> LANG=C sudo semanage login -l Login Name SELinux User MLS/MCS Range __default__ system_u s0 root root -s0:c0.c255 system_u system_u SystemLow-SystemHigh i notice this bug is fixed in F9 rawhide, but F8 has not

3 4

AW: RHEL5 + strict policy: Unprivileged user cron - "Unauthorized SELinux context"
by Harald Beugler-Bell 04 Dec '07

04 Dec '07

I got a similar problem when trying to run cron as root. It looks like selinux is unable to get the correct user context of the crond process crond[5587]: (*system*) NULL security context for user () crond[5587]: CRON (root) ERROR: failed to change SELinux context crond[5587]: CRON (root) ERROR: cannot set security context The file context of the cron file is set according to default context: $ ls -lZ /etc/cron.d/testing-cron -rw-r--r-- root root system_u:object_r:system_cron_spool_t:s0 /etc/cron.d/testing-cron $ ps -efZ | grep crond staff_u:system_r:crond_t:s0 root 14922 1 0 00:19 ? 00:00:00 /usr/sbin/crond start $ /usr/sbin/semanage login -l | egrep "root|system" root root s0-s0:c0.c1023 system_u system_u s0-s0:c0.c1023 bash-3.1# cat /etc/redhat-release Red Hat Enterprise Linux Server release 5 (Tikanga) vixie-cron-4.1-66.1.el5 libselinux-1.33.4-2.el5 libselinux-python-1.33.4-2.el5 selinux-policy-strict-2.4.6-79.el5 selinux-policy-2.4.6-79.el5 any help is welcome. thanks Hari ----- Ursprüngliche Mail ---- Von: Aleksander Adamowski <aleksander.adamowski.fedora(a)altkom.pl> An: fedora-selinux-list(a)redhat.com Gesendet: Mittwoch, den 28. November 2007, 16:10:58 Uhr Betreff: Re: RHEL5 + strict policy: Unprivileged user cron - "Unauthorized SELinux context" Stephen Smalley pisze: > On Wed, 2007-11-28 at 21:16 +0100, Aleksander Adamowski wrote: > >> crond[27249]: (apache) Unauthorized SELinux context, but SELinux in >> permissive mode, continuing (cron/apache) >> crond[29358]: (apache) NULL security context for user, but SELinux in >> permissive mode, continuing () >> > > Sounds like it just stayed in crond's context since it failed the check > and the system was permissive. Naturally, in enforcing mode, it would > have not executed the job at all. > > crond computes a context for the user's cron job in the usual manner, > then applies a entrypoint permission check between that context and the > file context on the crontab file (which gets picked up from a > combination of its creator and the parent directory). If that check > fails, then crond refuses to execute the crontab commands in that > process context. The check is intended to prevent injection of commands > from one context into another via crontab, unless authorized by policy > of course. > That's reasonable. > I'd have expected it to try to run the cron job in user_u:user_r: > user_crond_t:s0 since apache wouldn't have a specific entry in seusers. > So it would have wanted the crontab file to have user_cron_spool_t on > it, which would have happened if a user_t process created it. If > instead an admin created it and it got sysadm_cron_spool_t or > staff_cron_spool_t, that might explain it. So you could relabel it or > allow that permission. First though check the current label on the > crontab file. > Yes, you're right. That was precisely the cause. I've used "crontab -e -u apache" as root. The files in /var/spool/cron got sysadm_cron_spool_t type (the full context was root:object_r:sysadm_cron_spool_t). After running "fixfiles relabel /var/spool/cron/", the apache crontab got system_u:object_r:user_cron_spool_t. Now cron runs fine and doesn't log anything suspicious. IMHO crontab should be modified to relabel crontab files that are edited using the "-u" option, but this is a question to Dan - should I file a new bug to bugzilla.redhat.com on this? -- Best Regards, Aleksander Adamowski GG#: 274614 ICQ UIN: 19780575 http://olo.org.pl -- fedora-selinux-list mailing list fedora-selinux-list(a)redhat.com https://www.redhat.com/mailman/listinfo/fedora-selinux-list ___________________________________________________________ Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de

3 2

Problem with existing user directories on F*
by Tony Molloy 03 Dec '07

03 Dec '07

Hi, After an install of F8 I have a problem with pre-existing user directories. I did a full install of F8 with SELinux in enforcing mode and kept my existing user directories in /users. At the end of the install I did a "fixfiles relabel". Now when I try to login to my account I'm told that my home directory does not exist. It does. The problem appears to be SELinux because when I disable it everything works. Some info: ls -al| /home/testacc ( account created during the install ) drwx------ testacc testacc system_u:object_r:user_home_dir_t . drwxr-xr-x root root system_u:object_r:home_root_t .. -rw-r--r-- testacc testacc system_u:object_r:user_home_t .bash_logout .... ls -alZ /users/molloyt ( my home directory ) drwx------ molloyt csstaff system_u:object_r:default_t . drwxr-xr-x root root system_u:object_r:default_t .. -rw-r--r-- molloyt csstaff user_u:object_r:default_t 3rd-monday .... The SELinux permissions on the home directory, the owing directory and the contents of the home directory are wrong. So two questions: 1. how can I reset the permissions. 2. was the problem caused by the "fixfiles relabel" which I did at the end of the install. If I had unmounted the /users partition before I did that would I have been OK. Thanks, Tony

2 1

selinux out smarted itself. "Multiple different specifications" One FILE But two types labled ------------- (system_u:object_r:home_root_t:s0 and system_u:object_r:boot_t:s0).
by Roger Salisbury 03 Dec '07

03 Dec '07

----------- a challenge for selinux------------ Hi fellow selinux uses ... How can you fix labeling when the selinux tools don't allow you to. Selinux commands complain & refuse to work. Tradition selinux commands don't work. IE chcon, restorecon , fixfiles, setfiles etc..I Need an *expert* here, .......... PROBLEM is : my /boot directory has : :boot_t: and :home_root_t: .......... together labled --- see below. and I can't fix it. do we have to edit the "inode" directly?? Having two types on one file I believe should *never* happen but -- it has. Should be one ":boot_t:" or the other ":home_root_t:" but never *both*! I think I know how it happened -- but that's not the issue right now -- how do you fix it?? The security of selinux normaly is designed to prevent adhoc changes --- so this is why it is difficult... but with root password their would be a solution somehow. Thx Roger Salisbury Below is the setfiles display: /etc/selinux/targeted/contexts/files/file_contexts: Multiple same specifications for /boot/lost\+found/.*. /etc/selinux/targeted/contexts/files/file_contexts: Multiple different specifications for /boot (system_u:object_r:home_root_t:s0 and system_u:object_r:boot_t:s0). /etc/selinux/targeted/contexts/files/file_contexts: Multiple same specifications for /boot/\.journal. /etc/selinux/targeted/contexts/files/file_contexts: Multiple same specifications for /boot/lost\+found. setfiles: labeling files under /boot setfiles: labeling files under /boot matchpathcon_filespec_eval: hash table stats: 28 elements, 28/65536 buckets used, longest chain length 1 setfiles: Done.

2 1

policy compile error
by Clarkson, Mike R (US SSA) 03 Dec '07

03 Dec '07

I just downloaded the policy source from redhat (serefpolicy-2.4.6) and attempted to build a strict-mls loadable module policy and got the following compile error: Compiling mls base module /usr/bin/checkmodule -M base.conf -o tmp/base.mod /usr/bin/checkmodule: loading policy configuration from base.conf policy/modules/kernel/domain.te:174:ERROR 'unknown type ipsec_spd_t' at token ';' on line 10298: allow domain ipsec_spd_t:association polmatch; #line 174 /usr/bin/checkmodule: error(s) encountered while parsing configuration make: *** [tmp/base.mod] Error 1 Here is the offending portion of domain.te: ifdef(`enable_mls',` tunable_policy(`allow_netlabel',` kernel_raw_recvfrom_unlabeled(domain) kernel_tcp_recvfrom_unlabeled(domain) kernel_udp_recvfrom_unlabeled(domain) ') tunable_policy(`allow_ipsec_label',` ipsec_labeled(domain) ') ') Since domain is a base module and ipsec is a loadable module, doesn't the call to the ipsec_labeled interface need to be wrapped in an optional_policy statement? Since nesting conditional statements aren't supported, I had to comment out the tunable_policy statement to get this to compile: #tunable_policy(`allow_ipsec_label',` optional_policy(` ipsec_labeled(domain) ') #') What's the right fix for this?

2 1

Qustion regarding: selinux / perl-cgi / iptables
by Paul McAvoy 03 Dec '07

03 Dec '07

Hi, I was wondering if anyone has information or can direct me to more details on the following: I have been using a perl cgi script on a personal web-server of mine to control access to SSH. Essentially, it is a knock-knock system. I would go to a specific URL with the cgi, enter some information, and the perl script would add my ip address to the allowed list for SSH in the fire-wall. I have been working on learning the details with SElinux, and trying to come up with some rules to allow the script to work correctly. There appears to be some kind of conflict either related to the script itself, or being run through httpd and getting access to the IPTables command tools. The CGI script (written in perl) is SUID root. Httpd runs the script. The script will run the iptables command line tools to examine the table (to see if the ip address is already allowed), and also to add a new ip address to the allowed list. My current method of trying to create the appropriate policy is to continue testing the cgi-script, watching the audit log, and running audit2allow on the selected audit messages. My current policy is: ... require { type modules_conf_t; type modules_dep_t; type sysctl_modprobe_t; type boot_t; type httpd_sys_script_t; type modules_object_t; class capability net_raw; class dir { getattr search }; class file { read getattr }; class rawip_socket { getopt create }; } #============= httpd_sys_script_t ============== allow httpd_sys_script_t boot_t:dir getattr; allow httpd_sys_script_t modules_conf_t:file { read getattr }; allow httpd_sys_script_t modules_dep_t:file read; allow httpd_sys_script_t modules_object_t:dir search; allow httpd_sys_script_t self:capability net_raw; allow httpd_sys_script_t self:rawip_socket { getopt create }; ... So, my question boils down to this: (I'm running Fedora Core 7) Do I just continue running the audit2allow repeatedly to create a policy to do what I want? Is there a better way to solve this problem? I am concerned that just creating a policy to allow my script to run will create other more substantial holes. I am also open to creating a tool to update my iptables some other way. Maybe perl-cgi is not the best method? Thanks in advance for any information! - Paul -- Paul McAvoy <paulmcav(a)queda.net> http://www.queda.net

3 2

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

selinux November 2007