[refpolicy] restorecon needs to read bin_t symlinks

[domg472@gmail.com (Dominick Grift)]

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