[refpolicy] Which labelling for namespace filesystem?

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