[refpolicy] Which labelling for namespace filesystem?

[dac.override@gmail.com (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-----