From: domg472@gmail.com (Dominick Grift) Date: Sat, 19 Mar 2011 19:15:20 +0100 Subject: [refpolicy] restorecon needs to read bin_t symlinks In-Reply-To: <1300558205.18208.2.camel@tesla.lan> 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> Message-ID: <4D84F2B8.9050601@gmail.com> To: refpolicy@oss.tresys.com List-Id: refpolicy.oss.tresys.com -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 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 > -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAk2E8rgACgkQMlxVo39jgT+5eACggpsrHZ+BJFwCSbJ84XBElHhl 1HIAoIORwIj/twe6t/zo9YJexzBMvkz5 =QshM -----END PGP SIGNATURE-----