selinux April 2006

selinux@lists.fedoraproject.org

69 participants
97 discussions

Exporting NTFS filesystems over NFS (again)
by Göran Uddeborg 18 Apr '06

18 Apr '06

In a kind of a déja vu (https://www.redhat.com/archives/fedora-selinux-list/2005-October/msg00101.h…) I am no longer able to mount NTFS filesystems over NFS. I include the audit messages below. If I understand things correctly, the catch is that nfsd_t domain processes are not allowed to do getattr on a directories of the dosfs_t. Last time, under FC4, my problem was that the policy had not been properly reloaded on upgrades. The policy did actually allow the operation. But I do not understand how this could work now. The dosfs_t has attribute noxattrfs just like in the FC4 policy. But I can not find anything allowing nfsd_t to do getattr on noxattrfs. Looking at the code, my impression is that there ought to be "fs_list_noxattr_fs(nfsd_t)" delcarations in the nfs_export_all_rw/ro clauses in rpc.te. That would allow nfsd_t to access directories on noxattr filesystems. As it is now it is allowed to read FILES there (through "fs_read_noxattr_fs_files(nfsd_t)"), but not do anything with directories. (Except "search", so it can get to the files.) And that is apparently not enough. Am I just confused, or is there indeed a bug here? type=AVC msg=audit(1145364546.934:3950): avc: denied { getattr } for pid=14600 comm="rpc.mountd" name="/" dev=sda1 ino=5 scontext=root:system_r:nfsd_t:s0 tcontext=system_u:object_r:dosfs_t:s0 tclass=dir type=SYSCALL msg=audit(1145364546.934:3950): arch=40000003 syscall=195 success=no exit=-13 a0=56570dd1 a1=ffffcb7c a2=f7fa6ff4 a3=ffffcb7c items=1 pid=14600 auid=503 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 comm="rpc.mountd" exe="/usr/sbin/rpc.mountd" type=AVC_PATH msg=audit(1145364546.934:3950): path="/mnt/remote/teddi" type=CWD msg=audit(1145364546.934:3950): cwd="/var/lib/nfs" type=PATH msg=audit(1145364546.934:3950): item=0 name="/mnt/remote/teddi" flags=1 inode=5 dev=08:01 mode=040555 ouid=0 ogid=0 rdev=00:00

1 0

Re: Mount & SELinux problems, session saving in GNOME
by Stephen Smalley 17 Apr '06

17 Apr '06

On Sun, 2006-04-16 at 22:47 +0300, Lauri wrote: > Hi! > > With SELinux enabled, the system won't mount ReiserFS partitions, > SELinux will deny it: > > Apr 15 14:19:38 localhost kernel: ReiserFS: hdb1: found reiserfs > format "3.6" with standard journal > Apr 15 14:19:38 localhost kernel: ReiserFS: hdb1: using ordered data mode > Apr 15 14:19:38 localhost kernel: ReiserFS: hdb1: journal params: > device hdb1, size 8192, journal first block 18, max trans len 1024, max > batch 900, max commit age 30, max trans age 30 > Apr 15 14:19:38 localhost kernel: ReiserFS: hdb1: checking > transaction log (hdb1) > Apr 15 14:19:38 localhost kernel: ReiserFS: hdb1: Using r5 hash to > sort names > Apr 15 14:19:38 localhost kernel: audit(1145099700.155:2): avc: > denied { search } for pid=1278 comm="mount" name="/" dev=hdb1 ino=2 > scontext=system_u:system_r:mount_t:s0 > tcontext=system_u:object_r:unlabeled_t:s0 tclass=dir > Apr 15 14:19:38 localhost kernel: ReiserFS: hdb1: warning: > xattrs/ACLs enabled and couldn't find/create .reiserfs_priv. Failing mount. > > and mount will output: > > mount: Operation not supported Added fedora-selinux-list to the cc line. SELinux and the reiserfs xattr implementation (xattrs stored as regular files) don't get along presently. There are a couple of problems, one related to mount-time initialization (as above) since reiserfs ends up trying to search the root directory for the xattr root before SELinux has a chance to set up its security label incore, and one related to atomic labeling of new inodes. If you are using reiserfs for your primary filesystems (e.g. /, /usr, ...), then you likely just have to disable SELinux. If you are only using it for e.g. /home or other kinds of data repositories that can be handled at a single security label (with some loss in granularity of control), you may be able to get by via a local policy module and a context mount, details below. You can workaround the above specific denial by creating a policy module, ala: $ mkdir reiser $ cd reiser $ vi reiser.te i(nsert) # Declare the policy module, with a name and version. policy_module(reiser, 1.0) # Tell the module infrastructure what we need from the base policy # or other previously inserted modules. require { # Need these two types to already be defined. type mount_t; type unlabeled_t; }; # Define the content of the actual policy module. # In this case, just a single allow rule. allow mount_t unlabeled_t:dir search; :wq $ make -f /usr/share/selinux/devel/Makefile $ su # /usr/sbin/semodule -i reiser.pp This will add the permission required to search the root directory for the xattr subtree. (audit2allow also can be used to generate such modules, via the -M option). Then, you likely want to do a context mount to force all files in the reiserfs filesystem to a single label, because reiserfs doesn't support proper labeling of new inodes yet. Ala: # mount -o context=system_u:object_r:default_t:s0 <dirname> But replacing default_t with some type appropriate to the data stored there. If that works, then you'll want to add the context= option to your fstab file for future mounting. > SELinux also denys loading of some *.so files, for example a script of > XChat, I used following code to correct it: > > chcon -t texrel_shlib_t /usr/lib/xhat/*.so > > But this gets reset after reboot. It shouldn't be reset upon reboot unless a relabel occurred. Is /usr/lib on a reiserfs filesystem? If so, that is the problem. If not, then you can make the above change permanent across relabels/policy updates via semanage, e.g. # /usr/sbin/semanage fcontext -a -t textrel_shlib_t '/usr/lib/xhat/.*\.so(\.[^/]*)* Then a /sbin/restorecon -Rv /usr/lib/xhat shouldn't disturb those settings. > During shutdown, umount will fail if the name of the CD contains a > whitespace. Something like this is used (from /etc/mtab): > > /media/Led\040Zeppelin > > > When logging out, saving a session isn't offered as it was in FC4, so, > in order to save the session, I have to switch on automatic saving, log > out and then switch it off again. > > > Running on FC5, kernel 2.6.16-1.2080_FC5 or > 2.6.16-1.2080_2.rhfc5.cubbi_suspend2 (does it make any difference?). -- Stephen Smalley National Security Agency

3 5

Privoxy and Port 8080
by Joel Gomberg 17 Apr '06

17 Apr '06

I originally posted this message to the fedora users list. It was suggested that I might have better luck here. SELinux is blocking privoxy's access to my public library's online catalog: http://oaklandlibrary.org:8080/ipac20/ipac.jsp?profile=#focus SELinux denies access. With setenforce=0, access is permitted, so I'm sure it's a SELinux issue. After perusing the SELinux FAQ, I issued this command: semanage port -a -p tcp -t http_port_t 8080. The response was that port 8080 was already defined. The denial message is: type=AVC msg=audit(1145058006.474:1026): avc: denied { name_connect } for pid=13185 comm="privoxy" dest=8080 scontext=system_u:system_r:privoxy_t:s0 I received a suggestion to issue this command: semanage port -m -p tcp -t privoxy_t 8080 This changed the denial message slightly: type=AVC msg=audit(1145112509.543:104): avc: denied { name_connect } for pid=4137 comm="privoxy" dest=8080 scontext=system_u:system_r:privoxy_t:s0 tcontext=system_u:object_r:privoxy_t:s0 tclass=tcp_socket I then issued these commands: [root@alcibiades ~]# setenforce 0 [root@alcibiades ~]# audit2allow -i /var/log/audit/audit.log and received this output [relevant to Privoxy]: allow privoxy_t http_cache_port_t:tcp_socket name_connect; allow privoxy_t self:tcp_socket name_connect; I don't know how to proceed from here. -- Joel

2 2

Confining a Mono Application Using SELinux
by Benjy Grogan 17 Apr '06

17 Apr '06

Hello I'm trying to take a mono app from Extras and confine it using SELinux. At the moment it runs in the security context user_u:system_r:mono_t. I would like to create my own security context and run the mono app in that one. I've followed all the instructions at <http://fedora.redhat.com/docs/selinux-faq-fc5/> on 'How can I help write policy?' but it's useless if I don't have a domain for my application. I have read that you need to install the security contexts (as an rpm) before installing the rpm of the mono application. So I'm assuming that work has to be done to create a domain for the mono application, and then the mono application has to be forced to install in this domain. I'm not sure what makes an application run in the mono_t security context to begin with, and how would I go about changing that? Benjy

2 1

label for /var/cache/cups/jobs.cache, /var/cache/cups/remote.cache
by Tom London 17 Apr '06

17 Apr '06

Running rawhide, targeted enforcing. cupsd produces the following when trying to access jobs.cache and remote.cache in /var/cache/cups. tom type=PATH msg=audit(04/16/2006 09:56:19.228:50) : item=0 name=/var/cache/cups/remote.cache parent=2814387 dev=fd:00 mode=dir,775 ouid=root ogid=lp rdev=00:00 obj=system_u:object_r:var_t:s0 type=CWD msg=audit(04/16/2006 09:56:19.228:50) : cwd=/ type=SYSCALL msg=audit(04/16/2006 09:56:19.228:50) : arch=i386 syscall=open success=no exit=-13(Permission denied) a0=bfa652e8 a1=8241 a2=1b6 a3=8241 items=1 pid=2245 auid=unknown(4294967295) uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=(none) comm=cupsd exe=/usr/sbin/cupsd subj=system_u:system_r:cupsd_t:s0-s0:c0.c255 type=AVC msg=audit(04/16/2006 09:56:19.228:50) : avc: denied { write } for pid=2245 comm=cupsd name=remote.cache dev=dm-0 ino=2814393 scontext=system_u:system_r:cupsd_t:s0-s0:c0.c255 tcontext=system_u:object_r:var_t:s0 tclass=file ---- type=PATH msg=audit(04/16/2006 09:56:19.228:51) : item=0 name=/var/cache/cups/job.cache parent=2814387 dev=fd:00 mode=dir,775 ouid=root ogid=lp rdev=00:00 obj=system_u:object_r:var_t:s0 type=CWD msg=audit(04/16/2006 09:56:19.228:51) : cwd=/ type=SYSCALL msg=audit(04/16/2006 09:56:19.228:51) : arch=i386 syscall=open success=no exit=-13(Permission denied) a0=bfa652e8 a1=8241 a2=1b6 a3=8241 items=1 pid=2245 auid=unknown(4294967295) uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=(none) comm=cupsd exe=/usr/sbin/cupsd subj=system_u:system_r:cupsd_t:s0-s0:c0.c255 type=AVC msg=audit(04/16/2006 09:56:19.228:51) : avc: denied { write } for pid=2245 comm=cupsd name=job.cache dev=dm-0 ino=2814394 scontext=system_u:system_r:cupsd_t:s0-s0:c0.c255 tcontext=system_u:object_r:var_t:s0 tclass=file -- Tom London

2 1

Amanda client AVC
by Matthew Saltzman 16 Apr '06

16 Apr '06

My amanda clients are seeing the following: kernel: audit(1144217150.855:17): avc: denied { name_bind } for pid=3707 comm="sendbackup" src=697 scontext=system_u:system_r:amanda_t:s0 tcontext=system_u:object_r:reserved_port_t:s0 tclass=tcp_socket And they don't work. How to fix, please? TIA. -- Matthew Saltzman Clemson University Math Sciences mjs AT clemson DOT edu http://www.math.clemson.edu/~mjs

3 5

FC5: what context should I use for extra ext3 filesystems?
by Mike Carney 14 Apr '06

14 Apr '06

Greetings, I've got a couple of extra filesystems I use for various reasons which currently have a default_t context. I mount them under a new directory "/export", which I've set to mnt_t: /dev/sda9 on /export/0 type ext3 (rw) /dev/sdb9 on /export/1 type ext3 (rw) /dev/sdb10 on /export/2 type ext3 (rw) 203# ls -dZ /export /export/* drwxr-xr-x root root system_u:object_r:mnt_t /export/ drwxr-xr-x root root system_u:object_r:default_t /export/0/ drwxr-xr-x root root system_u:object_r:default_t /export/1/ drwxr-xr-x root root system_u:object_r:default_t /export/2/ 204# Any guidance as to what context should I set these file system mount points to? mnt_t? usr_t? How do I specify using semanage that I don't want the relabel to propogate to subdirectories? (e.g., <<none>>). Thanks in advance, Mike

2 4

SELinux enforcing disallows opening floppy drive in Nautilus
by J. K. Cliburn 14 Apr '06

14 Apr '06

When I try to open a floppy drive in Nautilus, nothing happens except the following message is logged in /var/log/messages. Apr 11 20:02:02 osprey kernel: audit(1144803722.736:26): avc: denied { write } for pid=6730 comm="mount" name="mtab" dev=hda3 ino=6843966 scontext=user_u:system_r:mount_t:s0 tcontext=user_u:object_r:etc_t:s0 tclass=file What do I need to do to enable opening the floppy drive? Thanks, Jay

5 16

error in today's rawhide update....
by Tom London 14 Apr '06

14 Apr '06

Doing today's update I get: Updating : selinux-policy-targeted ####################### [13/32] libsemanage.semanage_install_active: Could not copy /etc/selinux/targeted/modules/active/homedir_template to /etc/selinux/targeted/contexts/files/homedir_template. libsemanage.semanage_install_active: Could not copy /etc/selinux/targeted/modules/active/homedir_template to /etc/selinux/targeted/contexts/files/homedir_template. semodule: Failed! Here are the AVCs: type=AVC msg=audit(1144850575.266:27): avc: denied { write } for pid=3407 comm="semodule" name="files" dev=dm-0 ino=6667714 scontext=user_u:system_r:semanage_t:s0-s0:c0.c255 tcontext=system_u:object_r:file_context_t:s0 tclass=dir type=SYSCALL msg=audit(1144850575.266:27): arch=40000003 syscall=5 success=no exit=-13 a0=bff7d678 a1=241 a2=1a4 a3=1a4 items=1 pid=3407 auid=500 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts1 comm="semodule" exe="/usr/sbin/semodule" subj=user_u:system_r:semanage_t:s0-s0:c0.c255 type=CWD msg=audit(1144850575.266:27): cwd="/usr/share/selinux/targeted" type=PATH msg=audit(1144850575.266:27): item=0 name="/etc/selinux/targeted/contexts/files/homedir_template.tmp" parent=6667714 dev=fd:00 mode=040755 ouid=0 ogid=0 rdev=00:00 obj=system_u:object_r:file_context_t:s0 type=AVC msg=audit(1144850575.306:28): avc: denied { write } for pid=3407 comm="semodule" name="files" dev=dm-0 ino=6667714 scontext=user_u:system_r:semanage_t:s0-s0:c0.c255 tcontext=system_u:object_r:file_context_t:s0 tclass=dir type=SYSCALL msg=audit(1144850575.306:28): arch=40000003 syscall=5 success=no exit=-13 a0=bff7d678 a1=241 a2=1a4 a3=1a4 items=1 pid=3407 auid=500 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts1 comm="semodule" exe="/usr/sbin/semodule" subj=user_u:system_r:semanage_t:s0-s0:c0.c255 type=CWD msg=audit(1144850575.306:28): cwd="/usr/share/selinux/targeted" type=PATH msg=audit(1144850575.306:28): item=0 name="/etc/selinux/targeted/contexts/files/homedir_template.tmp" parent=6667714 dev=fd:00 mode=040755 ouid=0 ogid=0 rdev=00:00 obj=system_u:object_r:file_context_t:s0 tom -- Tom London

2 4

RE: Support for the NX client
by Frederick New 14 Apr '06

14 Apr '06

On 13. aprill 2006. a. 11:10, Aurelien Bompard wrote: > > I should be able to run "chcon -t testrel_shlib_t > /usr/NX/lib/libXcomp.so.1" > and make it work. Except this commands gives me : > > chcon: failed to change context of /usr/NX/lib/libXcomp.so.1 to > system_u:object_r:testrel_shlib_t: Invalid argument > > Is this type not valid on FC5 ? Which leads me to: how can I list the > available types on the system ? This is a small typo in the wiki. It should be textrel_shlib_t. Fred

4 5

← Newer
1
2
3
4
5
6
7
8
9
10
Older →

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

selinux April 2006