F13: Unable to mount ntfs-3g, option: 'context=' no longer supported?
by Dan Thurman
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?
13 years, 7 months
Re: secmark=XXX mapping
by Mr Dash Four
>>> 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.
13 years, 7 months
Re: secmark=XXX mapping
by Stephen Smalley
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
13 years, 7 months
secmark=XXX mapping
by Mr Dash Four
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"?
13 years, 7 months
genfscon question
by Roberto Sassu
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
13 years, 7 months
Labeling of ~/.local, ~/.config, ... owned by gnome though not gnome specific
by Nicky726
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)
13 years, 7 months
selinux bugzilla?
by mark
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"
13 years, 7 months
Fedora UBAC feature
by Roberto Sassu
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.
13 years, 7 months
What's the command...?
by mark
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
13 years, 7 months
openvpn and script execution
by Mr Dash Four
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.
13 years, 7 months