From: dac.override@gmail.com (Dominick Grift)
Date: Wed, 6 Jan 2016 20:55:45 +0100
Subject: [refpolicy] Which labelling for namespace filesystem?
In-Reply-To: <568D6E2D.5030003@m4x.org>
References: <568D5ED6.5040709@m4x.org> <20160106184428.GB15916@x250>
	<568D6E2D.5030003@m4x.org>
Message-ID: <20160106195543.GB1863@x250>
To: refpolicy@oss.tresys.com
List-Id: refpolicy.oss.tresys.com

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On Wed, Jan 06, 2016 at 08:42:37PM +0100, Nicolas Iooss wrote:
> On 01/06/2016 07:44 PM, Dominick Grift wrote:
> > On Wed, Jan 06, 2016 at 07:37:10PM +0100, Nicolas Iooss wrote:
> >> Hello,
> > 
> >> On the system I'm using to get refpolicy working with Arch Linux, I have
> >> these lines in audit.log:
> > 
> >>   type=AVC msg=audit(1451041210.334:794): avc:  denied  { read } for
> >>   pid=28829 comm="(ostnamed)" dev="nsfs" ino=4026532544
> >>   scontext=system_u:system_r:init_t
> >>   tcontext=system_u:object_r:unlabeled_t tclass=file permissive=1
> > 
> >>   type=AVC msg=audit(1451041210.334:794): avc:  denied  { open } for
> >>   pid=28829 comm="(ostnamed)" path="net:[4026532544]" dev="nsfs"
> >>   ino=4026532544 scontext=system_u:system_r:init_t
> >>   tcontext=system_u:object_r:unlabeled_t tclass=file permissive=1
> > 
> >> These accesses are caused by open("/proc/self/ns/net"...) in systemd
> >> setup_netns() function [1].  Indeed /proc/PID/ns/* symlinks target a
> >> special filesystem named nsfs which is used for setns() syscall [2].  As
> >> this filesystem is not defined in refpolicy, its files are currently
> >> unlabeled, which explains the audit records.
> > 
> >> To fix this, I see two options:
> > 
> >> * "fs_use_task nsfs gen_context(system_u:object_r:fs_t,s0);", so that
> >> programs already allowed to access the /proc/PID tree of a process can
> >> also open /proc/PID/ns/* files.
> > 
> >> * "genfscon nsfs / gen_context(system_u:object_r:nsfs_t,s0))", with a
> >> new fs type.  Programs using setns() will then need to be granted
> >> opening and reading nsfs_t files, in addition to be allowed using
> >> /proc/PID/ files of the target process.
> > 
> > Have you tried this option? I recall having tried it, and not getting
> > this to work.
> 
> Yes, in permissive mode only though.  I first added this to
> kernel/filesystem.te:
> 
>   type nsfs_t;
>   fs_type(nsfs_t)
>   genfscon nsfs / gen_context(system_u:object_r:nsfs_t,s0)
> 
> Then (after rebooting) audit.log showed:
> 
>   type=AVC msg=audit(1452106332.300:1811): avc:  denied  { read } for
>   pid=11125 comm="(ostnamed)" dev="nsfs" ino=4026532618
>   scontext=system_u:system_r:init_t tcontext=system_u:object_r:nsfs_t
>   tclass=file permissive=1
>   type=AVC msg=audit(1452106332.300:1811): avc:  denied  { open } for
>   pid=11125 comm="(ostnamed)" path="net:[4026532618]" dev="nsfs"
>   ino=4026532618 scontext=system_u:system_r:init_t
>   tcontext=system_u:object_r:nsfs_t tclass=file permissive=1
> 
> Adding the following lines to system/init.te in the
> ifdef(`init_systemd') block made these messages disappear when running
> "systemctl restart systemd-hostnamed.service":
> 
> 	optional_policy(`
> 		gen_require(`
> 			type nsfs_t;
> 		')
> 		allow init_t nsfs_t:file read_file_perms;
> 	')
> 
> Could you please describe the problem you had, so that I can see if I
> also have it?
> 
> Nicolas

I wonder if the flexibility that fs_use_tasks provides is a real benefit
over the "all-or-nothing" genfscon.

If it ends up all-or-nothing anyway's then fs_use_task is way too
expensive, if not then fs_use_task adds some neat controls over who can
access what.

> _______________________________________________
> refpolicy mailing list
> refpolicy at oss.tresys.com
> http://oss.tresys.com/mailman/listinfo/refpolicy

- -- 
Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8  02D5 3B6C 5F1D 2C7B 6B02
https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02
Dominick Grift
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQGcBAEBCAAGBQJWjXE7AAoJECV0jlU3+UdpgskMALvc5xuv8bU7+qXxszPklV4J
mgjprYJv7XZG2N3nqIh+zeGsmQAWGrHwi1dgAfj6HWJMBwOzbpICbjtU2brMLrK3
+0nabGP025TQASvWfEHcxkRj0BPdcH6EZsrN1seMWg/4mQQOORA+HRW/a42Jd3EA
s2MAWugDWl7teBgkrvB7cwZIapBF0ck79E8zEkLaSgH7jZ0JnMIVa6ZYj9WkIaF3
6vSwjdF0rXoZrPLQq62vV3igcuu8cbQZCmUdn2nlrwZBPNXfHwNDV7A8ACvYIPkz
wIfOm+beQ+yWgDBbuaopJ4ZoP6qB2wSmpFeYN0mfIHeBsyYn/KypwFqPdqmMkRmW
6NN234YKxdhbd66no9epQRM5PlsQ8lg8kDoh0P3xIESUvYe13OJu1uVhAyr8DVrI
AE2ZKC794AJYVJjNtNnFdVkwPrbetHF/WMIbyAVxoh9H6npnfZ/wfzCoSK0LQm+i
dlH3FNVrynsX23NwYXCgymxbkCHFQcyOAgv2CQM73w==
=dlmC
-----END PGP SIGNATURE-----