May 2008 - selinux - Fedora Mailing-Lists

Memory protection and system-config-securitylevel

by Kamil J. Dudek

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

14 years, 8 months

2
3
0 / 0

mount point labels

by Clarkson, Mike R (US SSA)

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

14 years, 8 months

3
7
0 / 0

xinetd rsync --daemon problems

by Chuck Anderson

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

15 years, 11 months

2
2
0 / 0

Sendmail milters in Fedora 8

by Paul Howarth

Since upgrading my mail server from Fedora 7 to Fedora 8, I've come across some problems with the sockets used for communication between sendmail and two of the "milter" plugins I'm using with it, namely milter-regex and spamass-milter. It's very likely that other milters will have similar issues. The sockets used are created when the milter starts, as follows: milter-regex: /var/spool/milter-regex/sock (var_spool_t, inherited from parent directory) spamass-milter: /var/run/spamass-milter/spamass-milter.sock (spamd_var_run_t, in policy) These are pretty well the upstream locations, though I'm open to moving the milter-regex socket from /var/spool to /var/run or elsewhere for consistency. Since moving to Fedora 8, I've had to add the following to local policy to get these milters working: allow sendmail_t spamd_var_run_t:dir { search getattr }; allow sendmail_t spamd_var_run_t:sock_file { getattr write }; allow sendmail_t var_spool_t:sock_file { getattr write }; allow sendmail_t initrc_t:unix_stream_socket { read write connectto }; The last of these is the strangest, and relates to Bug #425958 (https://bugzilla.redhat.com/show_bug.cgi?id=425958). Whilst the socket file itself has the context listed above, the unix domain socket that sendmail connects to is still initrc_t, as can be seen from the output of "netstat -lpZ": ... unix 2 [ ACC ] STREAM LISTENING 14142 5853/spamass-milter system_u:system_r:initrc_t:s0 /var/run/spamass-milter/spamass-milter.sock unix 2 [ ACC ] STREAM LISTENING 13794 5779/milter-regex system_u:system_r:initrc_t:s0 /var/spool/milter-regex/sock ... So, my questions are: 1. Why are the sockets still initrc_t? 2. Is this a kernel issue or a userspace issue that should be fixed in the milters? 3. Should there be a standard place for milter sockets to live, and if so, where? 4. How come this worked OK in Fedora 7 and previous releases? Paul.

15 years, 12 months

2
13
0 / 0

Re: Postfix pipe command and python scripts

by Fabrizio Buratta

> Looking at the policy postfix_pipe_t is able to write to postfix_spool_t > or postfix_var_run_t, So you could change the labeling of the file to > one of those context. > I realized that postfix_pipe_t ( postfix/pipe command actually runs under postfix_pipe_exec_t context ) cannot do write, add_name , remove_name and unlink either postfix_spool_t or postfix_var_run_t therefore i had to set it myself. I'll resume what i've done : 1 - I put my db in /var/spool/postfix/vacation 2 - chcon -u system_u -r object_r -t postfix_spool_t -R /var/spool/postfix/vacation 3 - chown -R postfix:vacation /var/spool/postfix/vacation 4 - i created vacation.te : module vacationpolicy 1.0; require { type postfix_pipe_t; type postfix_spool_t; class dir { write remove_name add_name }; class file { create unlink }; } #============= postfix_pipe_t ============== allow postfix_pipe_t postfix_spool_t:dir { write remove_name add_name }; allow postfix_pipe_t postfix_spool_t:file { create unlink }; 5 - I created a package and installed it It worked Thanks for your help! Fabrizio

16 years

1
0
0 / 0

fs_search_nfs lacks getattr

by Clarkson, Mike R (US SSA)

Shouldn't this have search_dir_perms to add in getattr? ######################################## ## <summary> ## Search directories on a NFS filesystem. ## </summary> ## <param name="domain"> ## <summary> ## Domain allowed access. ## </summary> ## </param> # interface(`fs_search_nfs',` gen_require(` type nfs_t; ') allow $1 nfs_t:dir search; ') This is from RHEL5.1. There are no other interfaces to add getattr unless I want to move to full read access with fs_list_nfs.

16 years

1
0
0 / 0

mock context

by Paul Howarth

Is there some reason why the context type of /usr/sbin/mock has reverted to bin_t in F9 from unconfined_notrans_exec_t in F8? The latter still seems to work OK for me in F9 and significantly reduces the number of spurious AVCs when using mock. Paul.

16 years

3
4
0 / 0

[RFC] Livecd-creator and selinux, we can play nice

by Eric Paris

So I've spent a fair bit of time the last 2 weeks trying to get livecd-creator and an selinux enforcing machine to play nicely together. It doesn't look like much, but from the point of view of the livecd creator I think the following patch is all we need. Working with rawhide as the host system I was able to build F8, F9 and rawhide livecd's with an enforcing machine. I wouldn't suggest jumping into enfocing builds just yet as there are still some policy issues I need to work out with the selinux people but I would like comments. Basically its quite simple, if selinux is on the host we create a fake /selinux which tells the install chroot lies. I've had to make some changes to some selinux libraries to support all this, but I think we are just about there. I'll probably backport some of the kernel changes to F9 after they are all tested and better settled but for now I'd like input on my livecd changes.... --- diff -Naupr /usr/lib/python2.5/site-packages/imgcreate/creator.py /root/imgcreate-5-28-08/creator.py --- /usr/lib/python2.5/site-packages/imgcreate/creator.py 2008-05-06 12:16:08.000000000 -0400 +++ /root/imgcreate-5-28-08/creator.py 2008-05-28 15:48:30.000000000 -0400 @@ -23,6 +23,7 @@ import sys import tempfile import shutil +import selinux import yum import rpm @@ -427,7 +428,7 @@ class ImageCreator(object): self._mount_instroot(base_on) - for d in ("/dev/pts", "/etc", "/boot", "/var/log", "/var/cache/yum"): + for d in ("/dev/pts", "/etc", "/boot", "/var/log", "/var/cache/yum", "/sys", "/proc", "/selinux"): makedirs(self._instroot + d) cachesrc = cachedir or (self.__builddir + "/yum-cache") @@ -439,10 +440,6 @@ class ImageCreator(object): (cachesrc, "/var/cache/yum")]: self.__bindmounts.append(BindChrootMount(f, self._instroot, dest)) - # /selinux should only be mounted if selinux is enabled (enforcing or permissive) - if kickstart.selinux_enabled(self.ks): - self.__bindmounts.append(BindChrootMount("/selinux", self._instroot, None)) - # Create minimum /dev origumask = os.umask(0000) devices = [('null', 1, 3, 0666), @@ -460,6 +457,37 @@ class ImageCreator(object): os.symlink('/proc/self/fd/2', self._instroot + "/dev/stderr") os.umask(origumask) + # if selinux exists on the host we need to lie to the chroot + if os.path.exists("/selinux/enforce"): + selinux_dir = self._instroot + "/selinux" + + # enforce=0 tells the chroot selinux is not enforcing + # policyvers=99 tell the chroot to make the highest version of policy it can + files = [('/enforce', '0'), + ('/policyvers', '99')] + for (file, value) in files: + fd = os.open(selinux_dir + file, os.O_WRONLY | os.O_TRUNC | os.O_CREAT) + os.write(fd, value) + os.close(fd) + + # we steal mls from the host system for now, might be best to always set it to 1???? + files = ["/selinux/mls"] + for file in files: + shutil.copyfile(file, self._instroot + file) + + # make /load -> /dev/null so chroot policy loads don't hurt anything + os.mknod(selinux_dir + "/load", 0666 | stat.S_IFCHR, os.makedev(1, 3)) + + # selinux is on whoo hooo + if kickstart.selinux_enabled(self.ks): + # label the fs like it is a root before the bind mounting + cmd = "/sbin/setfiles -F -r %s %s %s" % (self._instroot, selinux.selinux_file_context_path(), self._instroot) + os.system(cmd) + # these dumb things don't get magically fixed, so make the user generic + for f in ["/proc", "/sys", "/selinux"]: + cmd = "chcon -u system_u %s" % (self._instroot + f) + os.system(cmd) + self._do_bindmounts() os.symlink("../proc/mounts", self._instroot + "/etc/mtab") @@ -853,6 +881,18 @@ class LoopImageCreator(ImageCreator): (self._image, e)) def _unmount_instroot(self): + # if the system was running selinux clean up our lies + if os.path.exists("/selinux/enforce"): + files = ['/enforce', + '/policyvers', + '/mls', + '/load'] + for file in files: + try: + os.unlink(self._instroot + "/selinux" + file) + except OSError: + pass + if not self.__instloop is None: self.__instloop.cleanup() diff -Naupr /usr/lib/python2.5/site-packages/imgcreate/kickstart.py /root/imgcreate-5-28-08/kickstart.py --- /usr/lib/python2.5/site-packages/imgcreate/kickstart.py 2008-05-06 12:16:08.000000000 -0400 +++ /root/imgcreate-5-28-08/kickstart.py 2008-05-19 11:22:41.000000000 -0400 @@ -372,11 +372,11 @@ class SelinuxConfig(KickstartConfig): if ksselinux.selinux == ksconstants.SELINUX_DISABLED: return - if not os.path.exists(self.path("/sbin/restorecon")): + if os.path.exists(self.path("/sbin/restorecon")): + self.call(["/sbin/restorecon", "-l", "-v", "-r", "-F", "-e", "/proc", "-e", "/sys", "-e", "/dev", "-e", "/selinux", "/"]) + else: return - self.call(["/sbin/restorecon", "-l", "-v", "-r", "/"]) - def apply(self, ksselinux): if os.path.exists(self.path("/usr/sbin/lokkit")): args = ["/usr/sbin/lokkit", "-f", "--quiet", "--nostart"]

16 years

5
7
0 / 0

/tmp/lost+found on F9

by Paul Howarth

Being an old-fashioned sort of guy, I always create a separate partition (well, logical volume these days) for /tmp and various other top-level directories. Hence I have a directory /tmp/lost+found and every day I get an email from cron like this: Subject: Cron <root@goalkeeper> run-parts /etc/cron.daily Date: Tue, 27 May 2008 04:17:12 +0100 /etc/cron.daily/tmpwatch: error: failed to lstat /tmp/lost+found: Permission denied The following policy fixes this: policy_module(localmisc, 0.0.1) require { type tmpreaper_t; } # Allow tmpwatch to stat /tmp/lost+found files_getattr_lost_found_dirs(tmpreaper_t) Paul.

16 years

2
2
0 / 0

Selfmade policy not getting enforced on Fedora9

by Stefan Schleifer

Hey guys, As you might guess, I've a problem with my SELinux-policy under Fedora 9. I created a little test application 'demo' which reads some text from stdin and writes it in a config file /etc/hackbar/config.txt. Afterwarts, I developed a policy with types demo_t, demo_exec_t und demo_etc_t and allowed demo_exec_to to read/write demo_etc_t. Everything's fine. For testing purposes I changed /etc/hackbar/config.txt to type etc_t which demo_exec_t shouldn't be able to access as there doesn't exist an allow demo_exec_t r/w etc_t. [stefan@localhost policy]$ ls -Z /usr/local/bin/demo -rwsr-sr-x root root system_u:object_r:demo_exec_t:s0 /usr/local/ bin/demo [stefan@localhost policy]$ ls -Z /etc/hackbar/config.txt -rwxr-xr-x root root system_u:object_r:etc_t:s0 /etc/hackbar/ config.txt Again I ran the application but it is still allowed to change that file?! [stefan@localhost policy]$ /usr/local/bin/demo Enter text: foobar Read from file: foobar Regarding to standard UNIX permissions access should be granted as the demo-app has suid set, but shouldn't SELinux permitt access anyway in this case? SELinux is in enforcing mode. [stefan@localhost policy]$ /usr/sbin/sestatus SELinux status: enabled SELinuxfs mount: /selinux Current mode: enforcing Mode from config file: enforcing Policy version: 22 Policy from config file: targeted I'm rather confused... best regards, Stefan

16 years

4
5
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

selinux May 2008