[refpolicy] Which labelling for namespace filesystem?

[refpolicy] Which labelling for namespace filesystem?

[Nicolas Iooss]

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.

To my mind both options have benefits and drawbacks, and I am fine with
both.  If it matters, I have not found anything related to nsfs in
Fedora policy nor in Gentoo policy.  The only policy I have found using
nsfs is https://github.com/doverride/cilpolicy/ and it uses the first
option [4].

Which option should be considered for refpolicy?

Thanks,
Nicolas

PS: if anyone wonders what is this init_t process with a pid which is
not one and a weird comm field, it is actually the process which will
become systemd-hostnamed.  Its comm got modified by
rename_process_from_path() function [5].

[1] https://github.com/systemd/systemd/blob/v228/src/core/namespace.c#L682
[2] http://man7.org/linux/man-pages/man2/setns.2.html
[3]
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/fs/proc/namespaces.c?h=v4.3#n45
[4]
https://github.com/doverride/cilpolicy/blob/v0.1/sources/modules/base/fs/contexts.cil#L37
[5]
https://github.com/systemd/systemd/blob/v228/src/core/execute.c#L1003-L1032

[refpolicy] Which labelling for namespace filesystem?

[Dominick Grift]

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

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.

> 
> To my mind both options have benefits and drawbacks, and I am fine with
> both.  If it matters, I have not found anything related to nsfs in
> Fedora policy nor in Gentoo policy.  The only policy I have found using
> nsfs is https://github.com/doverride/cilpolicy/ and it uses the first
> option [4].
> 
> Which option should be considered for refpolicy?
> 
> Thanks,
> Nicolas
> 
> PS: if anyone wonders what is this init_t process with a pid which is
> not one and a weird comm field, it is actually the process which will
> become systemd-hostnamed.  Its comm got modified by
> rename_process_from_path() function [5].
> 
> [1] https://github.com/systemd/systemd/blob/v228/src/core/namespace.c#L682
> [2] http://man7.org/linux/man-pages/man2/setns.2.html
> [3]
> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/fs/proc/namespaces.c?h=v4.3#n45
> [4]
> https://github.com/doverride/cilpolicy/blob/v0.1/sources/modules/base/fs/contexts.cil#L37
> [5]
> https://github.com/systemd/systemd/blob/v228/src/core/execute.c#L1003-L1032
> _______________________________________________
> 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

iQGcBAEBCAAGBQJWjWCIAAoJECV0jlU3+UdpYKQMAKG8Qsz1uP8TWhmESnhy4A5Y
X43hI5Z+Tmj/5aw9QT5PrNotFI0waARNWUHMZiVBeELeNpbN7yYGtRX4g5EuqJP1
Wd0DsGmzz7PbomfHgTi373iiFZqG8vU61zBWrPgbyRkplF1FfciuHPmYyw0AKHbR
6A2saI5SFuCWBHyWFCf9SMtQrrqUeyLEbWUXCWVjA5I3Pn1htEomCeJJ6ZFLl7Ul
OSqhssTi97Qk8CEHco1papUUJQ8RDcxV70dZcugRnu5zB/GnWe4IXnJVyif/4SDN
sfi6u8AG726dMnpy36MR1bgTeZHzc7RalYrAlj3CdjCGNCt4OFcos32Fu3m4k6z0
3ojrsgX2tsYN8oY2Vx1RuQ+JnztY+TZc447wATJYlYEKT6Xgz7FcztliuMaSXOj1
XftaDxfbYgUe6/SngXs9wGUovTvvnxJI/1LWGRWvUumHG6nFEJr9toKI1faEnlaT
hamwGmJTJb+HAfI0NbDSe9gR4Bjc03FmdNikl37sBg==
=X+/y
-----END PGP SIGNATURE-----

[refpolicy] Which labelling for namespace filesystem?

[Dominick Grift]

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

On Wed, Jan 06, 2016 at 07:44:28PM +0100, 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.
> 
> > 
> > To my mind both options have benefits and drawbacks, and I am fine with
> > both.  If it matters, I have not found anything related to nsfs in
> > Fedora policy nor in Gentoo policy.  The only policy I have found using
> > nsfs is https://github.com/doverride/cilpolicy/ and it uses the first
> > option [4].

Yes and the superseding github.com/defensec/dssp

I ended up using fs_use_task

> > 
> > Which option should be considered for refpolicy?
> > 
> > Thanks,
> > Nicolas
> > 
> > PS: if anyone wonders what is this init_t process with a pid which is
> > not one and a weird comm field, it is actually the process which will
> > become systemd-hostnamed.  Its comm got modified by
> > rename_process_from_path() function [5].
> > 
> > [1] https://github.com/systemd/systemd/blob/v228/src/core/namespace.c#L682
> > [2] http://man7.org/linux/man-pages/man2/setns.2.html
> > [3]
> > https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/fs/proc/namespaces.c?h=v4.3#n45
> > [4]
> > https://github.com/doverride/cilpolicy/blob/v0.1/sources/modules/base/fs/contexts.cil#L37
> > [5]
> > https://github.com/systemd/systemd/blob/v228/src/core/execute.c#L1003-L1032
> > _______________________________________________
> > 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

- -- 
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

iQGcBAEBCAAGBQJWjWFaAAoJECV0jlU3+UdpIywL/3S03KszLxSK8sfYQ/FE+vr5
ON9qFBD/Lb9hB3z6E76Z83R2lm5XoUHI72HSdhnj9IT0xUxtNLcB6B7JJTA8sY8j
JdTZ67MhroHhaIWJUHFgSTtvSzfqKHTWHt5pICQ8+P499N5Vv2NfFzClhMBzm3lC
fnfEmJW3FMuHemLCiiJqJMhUpD6osty6p1oW+exrIrL+qEILu9bKvPGYIC7DVLFM
AjWEsTVmot6MZx5v0dWbwBQhvXDD3USTGgFoLRjNlRCks21p65BX2YBdoKDKvxNf
AzsLBlPTEADABv5f9ww4Umj9ovMzorikzvKd5/r2J22w3Vu4UVtdKUk6FXzbq75x
YU3mWZUuwBYBgT84CFSUtZyFNGlQoOV2xuK5EK41zNHtKAWyl9TZLt9T0wUkYMvI
ExGSNKjt9nvhXSJdaUFqYheI/lbS0kRGWGBGG34+A0YgGkXPo/N0ud69R30ENpYO
YvVXEaRzRsjrCZXVkcbZAMDDD18wel63oF/R/Wci0w==
=vfsR
-----END PGP SIGNATURE-----

[refpolicy] Which labelling for namespace filesystem?

[Nicolas Iooss]

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

[refpolicy] Which labelling for namespace filesystem?

[Dominick Grift]

-----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?

The problem i had was that i was not seeing these "read" file
events. The AVC denials above prove me wrong. I must have overlooked
something.

> 
> Nicolas
> _______________________________________________
> 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

iQGcBAEBCAAGBQJWjW9GAAoJECV0jlU3+UdpJ0oL/38K4OOud8bj7zyK9kdtUFMS
G49q0KKdxsmorEEuC02vG0UGuc0oPgdsykpKFSOiMIMh9Z0SdVbdch6T2AchzmGW
4fU7a+fI4vlD+lvjCrnpI7qFOprct/z/mCH9Lq9yDrwte6qwOEbK6j+La0t+tTqj
MX++e1x+Zr6nAZIZjqFEzyXAe+E40Zi3kHcQs8NxM02f6Tzf/6u3jvGa1iF9o/rY
wuomSb7t5w1YoSpi54v2JKGNspfi9h6P2IW4hjeZfclrhmEOa2w28UDnevCCP7a8
mo3V4u+MNdZs79n1tjwV7UAFbvjyxgZwl3X2qyHpgQua90Xq6LQS1ZRGRmcQ0kvW
D1ORBjWaNeYVgjWnA1dTYdeDqEUu0xPd6fnotTwooHsBIcrPt4sHCcidi22xgbBd
hptD04iPXM92ypLSZs1wDSqdQ48voOmY25s6zATcx+nhdMnYCHVHz/0etDNiWEWZ
4g4zEVKuOCXlBHOjUTmGgauIXjGpLsHbf/D75RLLUw==
=hM8E
-----END PGP SIGNATURE-----

[refpolicy] Which labelling for namespace filesystem?

[Dominick Grift]

On Wed, Jan 06, 2016 at 08:47:22PM +0100, Dominick Grift wrote:
> 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?
> 
> The problem i had was that i was not seeing these "read" file
> events. The AVC denials above prove me wrong. I must have overlooked
> something.

I faced this issue with "machinectl login", as i recall i was unable to
log into the container with machinectl login $container using genfscon
(i was using fs_t instead of nsfs_t), and i was not seeing the read
events. This prompted me to try other things and what caused me to
end up with fs_use_task

> 
> > 
> > Nicolas
> > _______________________________________________
> > 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

-- 
Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8  02D5 3B6C 5F1D 2C7B 6B02
https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02
Dominick Grift
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 648 bytes
Desc: not available
Url : http://oss.tresys.com/pipermail/refpolicy/attachments/20160106/ecbf0bcd/attachment.bin 

[refpolicy] Which labelling for namespace filesystem?

[Dominick Grift]

-----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-----