From: nicolas.iooss@m4x.org (Nicolas Iooss)
Date: Wed, 6 Jan 2016 19:37:10 +0100
Subject: [refpolicy] Which labelling for namespace filesystem?
Message-ID: <568D5ED6.5040709@m4x.org>
To: refpolicy@oss.tresys.com
List-Id: refpolicy.oss.tresys.com

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