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