selinux September 2010

selinux@lists.fedoraproject.org

26 participants
32 discussions

F13: Unable to mount ntfs-3g, option: 'context=' no longer supported?
by Dan Thurman 23 Sep '10

23 Sep '10

Some weeks ago, I have installed F13 on a system and for some time, I have successfully mounted all of my partitions as defined in my fstab file. But today, I have rebooted this F13 system and for some reason, it was unable to mount any of my ntfs filesystems with an error message: "ntfs-3g-mount: Invalid argument", for each ntfs partition defined in the /etc/fstab. I can manually mount a ntfs-3g partition to /mnt, I can see the contents and context and every thing seems fine for this ntfs partition. I did: # mount /dev/sdaX /mnt (it works) # mount -t ntfs-3g /dev/sdaX /mnt (it works) # mount -t ntfs-3g -o context="system_u:object_r:samba_share_t:s0" /dev/sdaX /mnt (breaks!) The problem is that the context=XXX option is no longer recognized, or so it seems. The fstab entry breaks as well for ntfs: LABEL=Ap1WD1 /md/Ap1WD1 ntfs-3g context="system_u:object_r:samba_share_t:s0" 0 0 So what is the problem?

4 5

Re: secmark=XXX mapping
by Mr Dash Four 21 Sep '10

21 Sep '10

>>> One item to note: xt_SECMARK.c is presently using selinux-specific >>> interfaces for mapping the security context string to a sid originally, >>> as well as to check permissions, manage refcounts, etc. So if you use >>> the LSM hooks for mapping the secid back to a context, there will be an >>> inconsistency in the interface. Likely they should all be LSM hooks and >>> both include/linux/selinux.h and security/selinux/exports.c should go >>> away. >>> >>> >> I found a way to alter the iptables source to get that information - see my >> own thread on the netfilter mailing list here - >> http://www.spinics.net/lists/netfilter/msg49094.html >> >> Whether the devs responsible for iptables/netfilter would agree to make >> these changes I am not sure - I patched my own iptables and it works! >> > > http://www.spinics.net/lists/netfilter/msg49106.html > > I don't think that approach is right. Exporting a number at ALL is > broken. It should only ever say the name. > I am aware of that and the proposed patch works as I did test it after Tom released it yesterday. As for your comment above - it is better than NOTHING. If you think that the current scenario, when I see meaningless number in the secmark field, helps me track the actual security context of the listed connection, then think again, because there is NO way I could know what number maps to which context. Tom's patch at least gives me that mapping when I list the mangle table, so it is a start and it works. Again, - the patch, if applied, is better than what currently exists in iptables. Also, 'exporting a number at all' is NOT broken - look at Tom's patch again - it does not break anything. > I'm not on netfilter list so I can't just in, but if you cc me on a > response to that thread I'll start responding there (hopefully soon > with a patch) > I'll quote the above as a separate post and will cc you in - no problem.

1 0

Re: secmark=XXX mapping
by Stephen Smalley 21 Sep '10

21 Sep '10

On Tue, 2010-09-21 at 09:40 -0400, Eric Paris wrote: > On Tue, Sep 21, 2010 at 8:10 AM, Stephen Smalley <sds(a)tycho.nsa.gov> wrote: > > On Fri, 2010-09-17 at 22:56 +0100, Mr Dash Four wrote: > >> > Is there any way I can link or map the number shown in the secmark > >> > field (secmark=XXX) when listing the current connections with "cat > >> > /proc/net/ip_conntrack" or "cat /proc/net/nf_conntrack"? > >> I should have been a bit clear - I need to map the number shown in the > >> secmark field to the actual SELinux context - is that possible? > > > > Not from userspace. So that likely ought to be mapping to a security > > context and displaying it instead of displaying the secmark (SID). > > Kernel issue. Kernel code can use security_secid_to_secctx() to map the > > value to a string, and then security_release_secctx() to free it > > afterward. > > Sorry I saw your e-mail and put it on my list of things to work on. > I'm playing with SECMARK a bit today so I'll try to send a kernel > patch to fix this up. One item to note: xt_SECMARK.c is presently using selinux-specific interfaces for mapping the security context string to a sid originally, as well as to check permissions, manage refcounts, etc. So if you use the LSM hooks for mapping the secid back to a context, there will be an inconsistency in the interface. Likely they should all be LSM hooks and both include/linux/selinux.h and security/selinux/exports.c should go away. -- Stephen Smalley National Security Agency

2 1

secmark=XXX mapping
by Mr Dash Four 21 Sep '10

21 Sep '10

Is there any way I can link or map the number shown in the secmark field (secmark=XXX) when listing the current connections with "cat /proc/net/ip_conntrack" or "cat /proc/net/nf_conntrack"?

2 2

genfscon question
by Roberto Sassu 20 Sep '10

20 Sep '10

Hi all i want to create a custom filesystem policy using the genfscon statement for labelling files. I need to specify rules with the wildcard character, in order to obtain the same behaviour for multiple subdirectories but this is currently unsupported (building of the policy fails). There are security/design concerns in order to introduce this feature or it can be added by patching the code? Thanks in advance for replies. Roberto Sassu

2 1

Labeling of ~/.local, ~/.config, ... owned by gnome though not gnome specific
by Nicky726 18 Sep '10

18 Sep '10

Hello, while working on confinement of selected KDE apps, I came to following issue: Directories ~/.config, ~/.local, ~/.local/share (and possibly others) are labeled as config_home_t, gconf_home_t and data_home_t all owned by gnome module. These directories are used by much more programs than just GNOME, ranging from KDE apps, pure Qt or GTK apps to for exaple ibus. User's trash is also put in one of those. Therefore I think, that the directories should be labeled with types that are owned by another application/DE unspecific module (Dominick Grift in conversation mentioned these are part of freedesktop specifications, so I guess it can be named eg. freedesktop). And their naming should also resign from application specific names, which is the case of gconf_home_t for ~/.local. Regards, Ondrej Vadinsky -- Don't it always seem to go That you don't know what you've got Till it's gone (Joni Mitchell)

2 6

selinux bugzilla?
by mark 17 Sep '10

17 Sep '10

Ok, I've had it. I never got around to filing the bug report for sealert (or is it audit, or setroubleshootd?), but I've been fighting to clear out tons of complaints (permissive mode), and it would be *really* nice it the damn thing gave me a real clue. So, if y'all wouldn't mind, what's the link, again, for the selinux bugzilla? mark "no, httpd_unified has been on"

3 2

Fedora UBAC feature
by Roberto Sassu 16 Sep '10

16 Sep '10

Hi all i want to use UBAC feature in order to isolate an user from each other. I created two users user1_u and user2_u mapped respectively to user1 and user2, and i assigned them the role user_r. Then i created two directories 'a' and 'b' labeled respectively user1_u:object_r:user_home_t:s0 and user2_u:object_r:user_home_t:s0. What i'm expecting is that user1 can access 'a' and not 'b', viceversa for user2, but user1 is allowed to access both directories.

2 4

What's the command...?
by mark 16 Sep '10

16 Sep '10

I remember months ago, someone mentioned the command to display valid context types. I need to change a type on a bunch of files, but it looks like http_sys_content_t isn't valid (CentOS 5.5), so I need to find what a valid one is. Thanks. mark

3 3

openvpn and script execution
by Mr Dash Four 16 Sep '10

16 Sep '10

I am trying to run openvpn within confined environment where the process runs under limited user/group (called _openvpn) and also using a specific SELinux context (allowed by openvpn itself when using the --setcon option). As part of this setup I also use the --iproute <ip-script>, --route-noexec and --route-up <route-up-script> options to provide the running of /sbin/ip and other such commands requiring privilege escalation (this is all done with sudo statements in those scripts). The role of the <ip-script> is to set the options of the tun0 device on startup and then reset it when needed on ip address change or shutdown. There is a 'filter' implemented in this script, which prohibits adding or deleting routes (they are explicitly set with the route-up-script during startup and are not touched until the shutdown script is called when they are deleted and previous routes are then restored). The role of the route-up-script is to set the routes, but just once (if called more than once it exits with status 0). The role of the shutdown script is to reset the tun0 device, remove routes related to the openvpn and restore previous routes on the internal network. The startup and shutdown scripts which are executed by openvpn init.d script. During startup and shutdown I am getting various AVCs, related, mainly to sudo, but also to openvpn itself. Here they are: During openvpn startup (sudo-related): type=AVC msg=audit(1284210049.555:96): avc: denied { getattr } for pid=2621 comm="<ip-script>" path="/usr/bin/sudo" dev=dm-0 ino=3226 scontext=unconfined_u:system_r:openvpn_t:s0 tcontext=system_u:object_r:sudo_exec_t:s0 tclass=file type=SYSCALL msg=audit(1284210049.555:96): arch=40000003 syscall=195 success=yes exit=0 a0=8372838 a1=bfb19650 a2=b89ff4 a3=8372838 items=0 ppid=2618 pid=2621 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=1 comm="<ip-script>" exe="/bin/bash" subj=unconfined_u:system_r:openvpn_t:s0 key=(null) type=AVC msg=audit(1284210049.558:97): avc: denied { execute } for pid=2621 comm="<ip-script>" name="sudo" dev=dm-0 ino=3226 scontext=unconfined_u:system_r:openvpn_t:s0 tcontext=system_u:object_r:sudo_exec_t:s0 tclass=file type=SYSCALL msg=audit(1284210049.558:97): arch=40000003 syscall=33 success=yes exit=0 a0=8372838 a1=1 a2=b89ff4 a3=8372838 items=0 ppid=2618 pid=2621 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=1 comm="<ip-script>" exe="/bin/bash" subj=unconfined_u:system_r:openvpn_t:s0 key=(null) type=AVC msg=audit(1284210049.559:98): avc: denied { read } for pid=2621 comm="<ip-script>" name="sudo" dev=dm-0 ino=3226 scontext=unconfined_u:system_r:openvpn_t:s0 tcontext=system_u:object_r:sudo_exec_t:s0 tclass=file type=SYSCALL msg=audit(1284210049.559:98): arch=40000003 syscall=33 success=yes exit=0 a0=8372838 a1=4 a2=b89ff4 a3=8372838 items=0 ppid=2618 pid=2621 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=1 comm="<ip-script>" exe="/bin/bash" subj=unconfined_u:system_r:openvpn_t:s0 key=(null) type=AVC msg=audit(1284210049.564:99): avc: denied { open } for pid=2622 comm="<ip-script>" name="sudo" dev=dm-0 ino=3226 scontext=unconfined_u:system_r:openvpn_t:s0 tcontext=system_u:object_r:sudo_exec_t:s0 tclass=file type=AVC msg=audit(1284210049.564:99): avc: denied { execute_no_trans } for pid=2622 comm="<ip-script>" path="/usr/bin/sudo" dev=dm-0 ino=3226 scontext=unconfined_u:system_r:openvpn_t:s0 tcontext=system_u:object_r:sudo_exec_t:s0 tclass=file type=SYSCALL msg=audit(1284210049.564:99): arch=40000003 syscall=11 success=yes exit=0 a0=8372838 a1=83716c0 a2=83713a8 a3=83716c0 items=0 ppid=2621 pid=2622 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=1 comm="sudo" exe="/usr/bin/sudo" subj=unconfined_u:system_r:openvpn_t:s0 key=(null) type=AVC msg=audit(1284210049.590:100): avc: denied { sys_resource } for pid=2622 comm="sudo" capability=24 scontext=unconfined_u:system_r:openvpn_t:s0 tcontext=unconfined_u:system_r:openvpn_t:s0 tclass=capability type=AVC msg=audit(1284210049.590:100): avc: denied { setrlimit } for pid=2622 comm="sudo" scontext=unconfined_u:system_r:openvpn_t:s0 tcontext=unconfined_u:system_r:openvpn_t:s0 tclass=process type=SYSCALL msg=audit(1284210049.590:100): arch=40000003 syscall=75 success=yes exit=0 a0=6 a1=bff9a1a8 a2=2afff4 a3=f01ce0 items=0 ppid=2621 pid=2622 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=1 comm="sudo" exe="/usr/bin/sudo" subj=unconfined_u:system_r:openvpn_t:s0 key=(null) type=AVC msg=audit(1284210049.636:102): avc: denied { setsched } for pid=2622 comm="sudo" scontext=unconfined_u:system_r:openvpn_t:s0 tcontext=unconfined_u:system_r:openvpn_t:s0 tclass=process type=SYSCALL msg=audit(1284210049.636:102): arch=40000003 syscall=97 success=yes exit=0 a0=0 a1=0 a2=0 a3=bff99b34 items=0 ppid=2621 pid=2622 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=1 comm="sudo" exe="/usr/bin/sudo" subj=unconfined_u:system_r:openvpn_t:s0 key=(null) Also during openvpn startup, but related to openvpn itself (the possible cause of this is the --setcon openvpn option!): type=AVC msg=audit(1284210049.853:110): avc: denied { setcurrent } for pid=2618 comm="openvpn" scontext=unconfined_u:system_r:openvpn_t:s0 tcontext=unconfined_u:system_r:openvpn_t:s0 tclass=process type=AVC msg=audit(1284210049.853:110): avc: denied { dyntransition } for pid=2618 comm="openvpn" scontext=unconfined_u:system_r:openvpn_t:s0 tcontext=system_u:system_r:openvpn_t:s0 tclass=process type=SYSCALL msg=audit(1284210049.853:110): arch=40000003 syscall=4 success=yes exit=31 a0=6 a1=97125d0 a2=1f a3=97125d0 items=0 ppid=1 pid=2618 auid=0 uid=498 gid=499 euid=498 suid=498 fsuid=498 egid=499 sgid=499 fsgid=499 tty=(none) ses=1 comm="openvpn" exe="/usr/sbin/openvpn" subj=system_u:system_r:openvpn_t:s0 key=(null) On openvpn shutdown, I get very similar sudo-related permissions as I did during startup: type=AVC msg=audit(1284209679.447:83): avc: denied { getattr } for pid=2589 comm="<ip-script>" path="/usr/bin/sudo" dev=dm-0 ino=3226 scontext=system_u:system_r:openvpn_t:s0 tcontext=system_u:object_r:sudo_exec_t:s0 tclass=file type=SYSCALL msg=audit(1284209679.447:83): arch=40000003 syscall=195 success=yes exit=0 a0=9509630 a1=bfadafa0 a2=491ff4 a3=9509630 items=0 ppid=2532 pid=2589 auid=0 uid=498 gid=499 euid=498 suid=498 fsuid=498 egid=499 sgid=499 fsgid=499 tty=(none) ses=1 comm="<ip-script>" exe="/bin/bash" subj=system_u:system_r:openvpn_t:s0 key=(null) type=AVC msg=audit(1284209679.453:84): avc: denied { execute } for pid=2589 comm="<ip-script>" name="sudo" dev=dm-0 ino=3226 scontext=system_u:system_r:openvpn_t:s0 tcontext=system_u:object_r:sudo_exec_t:s0 tclass=file type=SYSCALL msg=audit(1284209679.453:84): arch=40000003 syscall=33 success=yes exit=0 a0=9509630 a1=1 a2=491ff4 a3=9509630 items=0 ppid=2532 pid=2589 auid=0 uid=498 gid=499 euid=498 suid=498 fsuid=498 egid=499 sgid=499 fsgid=499 tty=(none) ses=1 comm="<ip-script>" exe="/bin/bash" subj=system_u:system_r:openvpn_t:s0 key=(null) type=AVC msg=audit(1284209679.457:85): avc: denied { read open } for pid=2590 comm="<ip-script>" name="sudo" dev=dm-0 ino=3226 scontext=system_u:system_r:openvpn_t:s0 tcontext=system_u:object_r:sudo_exec_t:s0 tclass=file type=AVC msg=audit(1284209679.457:85): avc: denied { execute_no_trans } for pid=2590 comm="<ip-script>" path="/usr/bin/sudo" dev=dm-0 ino=3226 scontext=system_u:system_r:openvpn_t:s0 tcontext=system_u:object_r:sudo_exec_t:s0 tclass=file type=SYSCALL msg=audit(1284209679.457:85): arch=40000003 syscall=11 success=yes exit=0 a0=9509630 a1=9508ae0 a2=9508888 a3=9508ae0 items=0 ppid=2589 pid=2590 auid=0 uid=498 gid=499 euid=0 suid=0 fsuid=0 egid=499 sgid=499 fsgid=499 tty=(none) ses=1 comm="sudo" exe="/usr/bin/sudo" subj=system_u:system_r:openvpn_t:s0 key=(null) type=AVC msg=audit(1284209679.763:86): avc: denied { sys_resource } for pid=2590 comm="sudo" capability=24 scontext=system_u:system_r:openvpn_t:s0 tcontext=system_u:system_r:openvpn_t:s0 tclass=capability type=AVC msg=audit(1284209679.763:86): avc: denied { setrlimit } for pid=2590 comm="sudo" scontext=system_u:system_r:openvpn_t:s0 tcontext=system_u:system_r:openvpn_t:s0 tclass=process type=SYSCALL msg=audit(1284209679.763:86): arch=40000003 syscall=75 success=yes exit=0 a0=6 a1=bf9cfb38 a2=6dbff4 a3=fc1ce0 items=0 ppid=2589 pid=2590 auid=0 uid=498 gid=499 euid=0 suid=0 fsuid=0 egid=499 sgid=499 fsgid=499 tty=(none) ses=1 comm="sudo" exe="/usr/bin/sudo" subj=system_u:system_r:openvpn_t:s0 key=(null) The above AVCs were produced when I switched SELinux to permissive mode (setenforce 0) otherwise I wasn't able to run openvpn at all. Is there any way I could get rid of those AVCs? I am also not sure whether { setcurrent dyntransition } process permissions should be allowed in the openvpn.te as, as far as I can see, these are directly related to the use of the --setcon openvpn option.

3 24

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

selinux September 2010