Exporting NTFS filesystems over NFS (again)
by Göran Uddeborg
In a kind of a déja vu
(https://www.redhat.com/archives/fedora-selinux-list/2005-October/msg00101...)
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
17 years, 1 month
Re: Mount & SELinux problems, session saving in GNOME
by Stephen Smalley
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
17 years, 1 month
Privoxy and Port 8080
by Joel Gomberg
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
17 years, 1 month
Confining a Mono Application Using SELinux
by Benjy Grogan
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
17 years, 1 month
label for /var/cache/cups/jobs.cache, /var/cache/cups/remote.cache
by Tom London
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
17 years, 1 month
Amanda client AVC
by Matthew Saltzman
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
17 years, 1 month
FC5: what context should I use for extra ext3 filesystems?
by Mike Carney
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
17 years, 1 month
SELinux enforcing disallows opening floppy drive in Nautilus
by J. K. Cliburn
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
17 years, 1 month
error in today's rawhide update....
by Tom London
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
17 years, 1 month
RE: Support for the NX client
by Frederick New
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
17 years, 1 month
