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