From: dwalsh@redhat.com (Daniel J Walsh) Date: Tue, 22 Mar 2011 08:12:52 -0400 Subject: [refpolicy] restorecon needs to read bin_t symlinks In-Reply-To: <4D84F2B8.9050601@gmail.com> References: <1300549506.3034.24.camel@tesla.lan> <4D84D11C.5090909@gmail.com> <1300555758.3034.35.camel@tesla.lan> <4D84E955.8030304@gmail.com> <1300556614.3034.47.camel@tesla.lan> <4D84EBC4.2050504@gmail.com> <1300557149.3034.52.camel@tesla.lan> <4D84EE9B.20604@gmail.com> <1300558205.18208.2.camel@tesla.lan> <4D84F2B8.9050601@gmail.com> Message-ID: <4D889244.3040608@redhat.com> To: refpolicy@oss.tresys.com List-Id: refpolicy.oss.tresys.com -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 03/19/2011 02:15 PM, Dominick Grift wrote: > On 03/19/2011 07:10 PM, Guido Trentalancia wrote: >> On Sat, 19/03/2011 at 18.57 +0100, Dominick Grift wrote: >>> On 03/19/2011 06:52 PM, Guido Trentalancia wrote: >>>> On Sat, 19/03/2011 at 18.45 +0100, Dominick Grift wrote: >>>>> On 03/19/2011 06:43 PM, Guido Trentalancia wrote: >>>>>> On Sat, 19/03/2011 at 18.35 +0100, Dominick Grift wrote: >>>>>>> On 03/19/2011 06:29 PM, Guido Trentalancia wrote: >>>>>>>> Good afternoon Dominick ! >>>>>>>> >>>>>>>> Off list... >>>>>>>> > >> [cut] > >>>>>>>>> This interface is already available in corecommands module: >>>>>>>>> >>>>>>>>> corecmd_read_bin_symlinks() >>>>>>>>> >>>>>>>>> can you enclose the AVC denial that you were seeing? >>>>>>>>> >>>>>>>>> It is probably this: >>>>>>>>> >>>>>>>>> ls -alZ /sbin/restorecon >>>>>>>>> lrwxrwxrwx. root root system_u:object_r:bin_t:s0 /sbin/restorecon >>>>>>>>> - -> setfiles >>>>>>>> >>>>>>>> Actually I am not even sure it's due to the symlink... >>>>>>>> >>>>>>>> It must be the annoying problems that I am experiencing from the >>>>>>>> console. >>>>>>>> >>>>>>>> From ps: >>>>>>>> >>>>>>>> root:sysadm_r:setfiles_t:s0-s0:c0.c1023 17979 tty2 R+ 0:00 restorecon >>>>>>>> -R /usr/bin/ >>>>>>>> >>>>>>>> From the audit logs: >>>>>>>> >>>>>>>> type=AVC msg=audit(1300548791.446:602): avc: denied { read } for >>>>>>>> pid=16018 comm="restorecon" name="zcat" dev=dm-1 ino=21047 >>>>>>>> scontext=root:sysadm_r:setfiles_t:s0-s0:c0.c1023 >>>>>>>> tcontext=system_u:object_r:bin_t:s0 tclass=lnk_file >>>>>>> >>>>>>> files_read_all_symlinks(setfiles_t) >>>>>>> >>>>>>> Fedora has files_dontaudit_read_symlinks(setfiles_t) instead. Not sure >>>>>>> why she silently denies it. >>>>>> >>>>>> Perhaps setfiles can read the target of the symlink so it's not strictly >>>>>> necessary to read the symlink itself ? >>>>>> >>>>>> In any case, it doesn't make much sense to me files_read_usr_symlinks() >>>>>> and not files_read_all_symlinks() ! >>>>>> >>>>> >>>>> You can drop files_read_usr_symlinks() if you add >>>>> files_dontaudit_read_all_symlinks() >>>> >>>> But why all of this ? What's the security risk of reading a symlink for >>>> a tool such as restorecon ? But first of all, what does reading a >>>> symlink actually mean ? I take that it is just getting the target file >>>> path... If it is so, then what's the security risk ? > >> We need to get more insight into the above... > > > I think dwalsh can tell you that best since he chose to dontaudit it. > Either that or you try it out. > > for example create a synlink in /etc to an object in /var then > restorecon -R -v /etc and see if it also restores the object in /var (in > permissive mode for testing purpose) > >>>>>>>> And more are showing up... >>>>>>>> >>>>>>>> type=AVC msg=audit(1300554461.199:677): avc: denied { create } for >>>>>>>> pid=16248 >>>>>>>> comm="restorecon" scontext=root:sysadm_r:setfiles_t:s0-s0:c0.c1023 >>>>>>>> tcontext=root:sysadm_r:setfiles_t:s0-s0:c0.c1023 >>>>>>>> tclass=netlink_audit_socket >>>>>>> >>>>>>> logging_send_audit_msgs(setfiles_t) >>>>>> >>>>>> Fedora ? >>>>> >>>>> Yes the above logging_send_audit_msgs is also in fedora policy >>>>> >>>>>> >>>>>>>> It must be some misconfiguration with sysadm. >>>>>>>> >>>>>>>> What do you say ? >>>>>>>> Regards, >>>>>>>> >>>>>>>> Guido >>>>>> >>>>>> Do you think a patch could be of interest to others (I did not tag it >>>>>> with [PATCH] because I wasn't sure) ? >>>>>> >>>>>> By the way, on some of your messages of the last couple of days I read >>>>>> that you do not feel very confident with doing C programming for >>>>>> developing the tools and libraries. If you have ideas perhaps I can try >>>>>> helping out... >>>> >>>> So, do you think a patch would be of interest to others ? >>>> >>>> Regards, >>>> >>>> Guido >>>> >>> >>> if it works (test the changes) and if you present/describe it well, then >>> i guess it could be of interest to refpolicy, sure. > >> Before submitting I need to be sure of what means "reading a symlink". >> So that I can decide whether to allow or dontaudit. > >> See above. > >>> You could split above up into two patches so that if one rule (patch) is >>> not accepted then the other rule (patch) still has a chance of getting >>> accepted. >>> >>> Fedora's setfiles policy has many more rules compared to refpolicys'. So >>> i assume that there is plenty more that can be improved. > >> Regards, > >> Guido > > _______________________________________________ refpolicy mailing list refpolicy at oss.tresys.com http://oss.tresys.com/mailman/listinfo/refpolicy I think we want to avoid restorecon reading symbolic links to avoid mislabels, as Chris pointed out. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAk2IkkQACgkQrlYvE4MpobPicACgpmYAEnBBZh4NitdQ492DoUGc qV0AoMTImiNB2QQ7S9jvep8m16vA12gf =CBrw -----END PGP SIGNATURE-----