From: dominick.grift@gmail.com (Dominick Grift) Date: Wed, 29 Aug 2012 22:31:06 +0200 Subject: [refpolicy] [PATCH v1 5/5] Udev's tables (run data) is stored in directories In-Reply-To: <1346271637.15262.13.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> <1346271637.15262.13.camel@d30.localdomain> Message-ID: <1346272266.15262.19.camel@d30.localdomain> To: refpolicy@oss.tresys.com List-Id: refpolicy.oss.tresys.com On Wed, 2012-08-29 at 22:20 +0200, Dominick Grift wrote: > > 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. /var/run/udev(/.*)? should be type udev_var_run_t i believe # matchpathcon /var/run/udev/ /var/run/udev system_u:object_r:udev_var_run_t:s0 # ls -alZ /var/run/udev/ drwxr-xr-x. root root system_u:object_r:udev_var_run_t:s0 . drwxr-xr-x. root root system_u:object_r:var_run_t:s0 .. srw-------. root root system_u:object_r:udev_var_run_t:s0 control drwxr-xr-x. root root system_u:object_r:udev_var_run_t:s0 data drwxr-xr-x. root root system_u:object_r:udev_var_run_t:s0 links -rw-r--r--. root root system_u:object_r:udev_var_run_t:s0 queue.bin drwxr-xr-x. root root system_u:object_r:udev_var_run_t:s0 rules.d drwxr-xr-x. root root system_u:object_r:udev_var_run_t:s0 tags drwxr-xr-x. root root system_u:object_r:udev_var_run_t:s0 watch Either that or Fedora has it wrong as well > > > Wkr, > > > Sven Vermeulen > > > _______________________________________________ > > > refpolicy mailing list > > > refpolicy at oss.tresys.com > > > http://oss.tresys.com/mailman/listinfo/refpolicy > > > > > >