From: dominick.grift@gmail.com (Dominick Grift)
Date: Wed, 29 Aug 2012 22:20:37 +0200
Subject: [refpolicy] [PATCH v1 5/5] Udev's tables (run data) is stored
 in directories
In-Reply-To: <1346270641.15262.10.camel@d30.localdomain>
References: <1346268526-22260-1-git-send-email-sven.vermeulen@siphos.be>
	<1346268526-22260-6-git-send-email-sven.vermeulen@siphos.be>
	<1346269075.15262.3.camel@d30.localdomain>
	<20120829195527.GA22738@siphos.be>
	<1346270641.15262.10.camel@d30.localdomain>
Message-ID: <1346271637.15262.13.camel@d30.localdomain>
To: refpolicy@oss.tresys.com
List-Id: refpolicy.oss.tresys.com



On Wed, 2012-08-29 at 22:04 +0200, Dominick Grift wrote:
> 
> On Wed, 2012-08-29 at 21:55 +0200, Sven Vermeulen wrote:
> > On Wed, Aug 29, 2012 at 09:37:55PM +0200, Dominick Grift wrote:
> > > > -# create udev database in /dev/.udevdb
> > > > -allow udev_t udev_tbl_t:file manage_file_perms;
> > > > +allow udev_t udev_tbl_t:dir relabelto;
> > > > +manage_dirs_pattern(udev_t, udev_tbl_t, udev_tbl_t)
> > > > +manage_files_pattern(udev_t, udev_tbl_t, udev_tbl_t)
> > > > +manage_lnk_files_pattern(udev_t, udev_tbl_t, udev_tbl_t)
> > > > +
> > > >  dev_filetrans(udev_t, udev_tbl_t, file)
> > > 
> > > This doesnt make sense to me.
> > > 
> > > First we had:
> > > 
> > > allow udev_t udev_tbl_t:file manage_file_perms;
> > > dev_filetrans(udev_t, udev_tbl_t, file)
> > > 
> > > with these specs:
> > > 
> > > /dev/\.udev(/.*)? --	gen_context(system_u:object_r:udev_tbl_t,s0)
> > > /dev/\.udevdb	--	gen_context(system_u:object_r:udev_tbl_t,s0)
> > > /dev/udev\.tbl	--	gen_context(system_u:object_r:udev_tbl_t,s0)
> > > 
> > > What does this tell me?
> > > 
> > > Well there shouldnt be any dirs and symlinks with type udev_tbl_t.
> > > 
> > > Only files. dirs and lnk_files should be device_t.
> > 
> > Well, the udev code (looking at udev-182 here) has the code for relabeling
> > in it. For instance, when copy_dev_dir is called, it has
> > 
> > #v+
> >                         udev_selinux_setfscreateconat(udev, dirfd(dir_to), dent->d_name, S_IFDIR|0755);
> >                         mkdirat(dirfd(dir_to), dent->d_name, 0755);
> >                         udev_selinux_resetfscreatecon(udev);
> > #v-
> > 
> > I believe this is the source, but I'm no master in this. I mainly based
> > myself on the denials and errors I got. If I put in an "auditallow" to show
> > this, this is the result:
> > 
> > #v+
> > testsys ~ # grep grant /var/log/avc.log
> > Aug 29 21:51:23 testsys kernel: [    3.339771] type=1400 audit(1346269880.338:6): avc:  granted  { create } for  pid=1162
> > comm="systemd-udevd" name="data" scontext=system_u:system_r:udev_t tcontext=system_u:object_r:udev_tbl_t tclass=dir
> > #v-
> > 
> > This, btw, is for the /var/run/udev/data location, and the file contexts for
> > udev does hold this as a udev_tbl_t currently:
> > 
> > #v+
> > testsys ~ # grep udev_tbl_t udev.fc
> > /dev/\.udev(/.*)? --    gen_context(system_u:object_r:udev_tbl_t,s0)
> > /dev/\.udevdb   --      gen_context(system_u:object_r:udev_tbl_t,s0)
> > /dev/udev\.tbl  --      gen_context(system_u:object_r:udev_tbl_t,s0)
> > /var/run/udev(/.*)?     gen_context(system_u:object_r:udev_tbl_t,s0)
> > #v-
> > 
> > (last line)
> > 
> 
> Thats just udev trying to be smart. It should stick to its own business.
> 
> dirs and symlinks in /dev should be type device_t as evidence by the
> file context specs and current policy.
> 
> /var/run/udev is a different story
> 

Oops sorry didnt take time to think again.

Weird. so theres a file context spec : 

/var/run/udev(/.*)?     gen_context(system_u:object_r:udev_tbl_t,s0)

but no rules to support it?

Strange indeed.

> > Wkr,
> > 	Sven Vermeulen
> > _______________________________________________
> > refpolicy mailing list
> > refpolicy at oss.tresys.com
> > http://oss.tresys.com/mailman/listinfo/refpolicy
> 
>