[refpolicy] restorecon needs to read bin_t symlinks

[refpolicy] restorecon needs to read bin_t symlinks

[Guido Trentalancia]

Hello !

I have recently started to experience AVC denials due to restorecon
trying to read bin_t symbolic links. It is not entirely clear to me what
is triggering this, since everything has been working fine for a long
time.

In any case, I had to apply the following patch on my system (and I am
still asking myself why not files_read_all_symlinks then ?):

diff -pruN refpolicy-git-17032011/policy/modules/kernel/files.if refpolicy-git-17032011-restorecon/policy/modules/kernel/files.if
--- refpolicy-git-17032011/policy/modules/kernel/files.if	2011-02-22 18:50:44.460551925 +0100
+++ refpolicy-git-17032011-restorecon/policy/modules/kernel/files.if	2011-03-19 16:21:01.701636861 +0100
@@ -4425,7 +4425,28 @@ interface(`files_relabelfrom_usr_files',
 
 ########################################
 ## <summary>
-##	Read symbolic links in /usr.
+##	Read symbolic links with type
+##	bin_t (usually located in /bin,
+##	/sbin, /usr/bin and /usr/sbin).
+## </summary>
+## <param name="domain">
+##	<summary>
+##	Domain allowed access.
+##	</summary>
+## </param>
+#
+interface(`files_read_bin_symlinks',`
+	gen_require(`
+		type bin_t;
+	')
+
+	read_lnk_files_pattern($1, bin_t, bin_t)
+')
+
+########################################
+## <summary>
+##	Read symbolic links with type
+##	usr_t (usually located in /usr).
 ## </summary>
 ## <param name="domain">
 ##	<summary>
diff -pruN refpolicy-git-17032011/policy/modules/system/selinuxutil.te refpolicy-git-17032011-restorecon/policy/modules/system/selinuxutil.te
--- refpolicy-git-17032011/policy/modules/system/selinuxutil.te	2011-01-17 19:36:10.814131755 +0100
+++ refpolicy-git-17032011-restorecon/policy/modules/system/selinuxutil.te	2011-03-19 16:16:13.198810817 +0100
@@ -527,6 +527,7 @@ files_read_etc_runtime_files(setfiles_t)
 files_read_etc_files(setfiles_t)
 files_list_all(setfiles_t)
 files_relabel_all_files(setfiles_t)
+files_read_bin_symlinks(setfiles_t)
 files_read_usr_symlinks(setfiles_t)
 
 fs_getattr_xattr_fs(setfiles_t)

[refpolicy] restorecon needs to read bin_t symlinks

[Dominick Grift]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 03/19/2011 04:45 PM, Guido Trentalancia wrote:
> Hello !
> 
> I have recently started to experience AVC denials due to restorecon
> trying to read bin_t symbolic links. It is not entirely clear to me what
> is triggering this, since everything has been working fine for a long
> time.
> 
> In any case, I had to apply the following patch on my system (and I am
> still asking myself why not files_read_all_symlinks then ?):
> 
> diff -pruN refpolicy-git-17032011/policy/modules/kernel/files.if refpolicy-git-17032011-restorecon/policy/modules/kernel/files.if
> --- refpolicy-git-17032011/policy/modules/kernel/files.if	2011-02-22 18:50:44.460551925 +0100
> +++ refpolicy-git-17032011-restorecon/policy/modules/kernel/files.if	2011-03-19 16:21:01.701636861 +0100
> @@ -4425,7 +4425,28 @@ interface(`files_relabelfrom_usr_files',
>  
>  ########################################
>  ## <summary>
> -##	Read symbolic links in /usr.
> +##	Read symbolic links with type
> +##	bin_t (usually located in /bin,
> +##	/sbin, /usr/bin and /usr/sbin).
> +## </summary>
> +## <param name="domain">
> +##	<summary>
> +##	Domain allowed access.
> +##	</summary>
> +## </param>
> +#
> +interface(`files_read_bin_symlinks',`

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

> +	gen_require(`
> +		type bin_t;
> +	')
> +
> +	read_lnk_files_pattern($1, bin_t, bin_t)
> +')
> +
> +########################################
> +## <summary>
> +##	Read symbolic links with type
> +##	usr_t (usually located in /usr).
>  ## </summary>
>  ## <param name="domain">
>  ##	<summary>
> diff -pruN refpolicy-git-17032011/policy/modules/system/selinuxutil.te refpolicy-git-17032011-restorecon/policy/modules/system/selinuxutil.te
> --- refpolicy-git-17032011/policy/modules/system/selinuxutil.te	2011-01-17 19:36:10.814131755 +0100
> +++ refpolicy-git-17032011-restorecon/policy/modules/system/selinuxutil.te	2011-03-19 16:16:13.198810817 +0100
> @@ -527,6 +527,7 @@ files_read_etc_runtime_files(setfiles_t)
>  files_read_etc_files(setfiles_t)
>  files_list_all(setfiles_t)
>  files_relabel_all_files(setfiles_t)
> +files_read_bin_symlinks(setfiles_t)
>  files_read_usr_symlinks(setfiles_t)
>  
>  fs_getattr_xattr_fs(setfiles_t)
> 
> 
> _______________________________________________
> refpolicy mailing list
> refpolicy at oss.tresys.com
> http://oss.tresys.com/mailman/listinfo/refpolicy

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.16 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iEYEARECAAYFAk2E0RwACgkQMlxVo39jgT/bewCeIx7fIXi7bVEc5sf3sDcGzgVf
9VIAnR+VaqetXeP4kLIFNPJ+GjmMFGqG
=g4zw
-----END PGP SIGNATURE-----

[refpolicy] restorecon needs to read bin_t symlinks

[Guido Trentalancia]

On Sat, 19/03/2011 at 16.51 +0100, Dominick Grift wrote:
> On 03/19/2011 04:45 PM, Guido Trentalancia wrote:
> > Hello !
> > 
> > I have recently started to experience AVC denials due to restorecon
> > trying to read bin_t symbolic links. It is not entirely clear to me what
> > is triggering this, since everything has been working fine for a long
> > time.
> > 
> > In any case, I had to apply the following patch on my system (and I am
> > still asking myself why not files_read_all_symlinks then ?):
> > 
> > diff -pruN refpolicy-git-17032011/policy/modules/kernel/files.if refpolicy-git-17032011-restorecon/policy/modules/kernel/files.if
> > --- refpolicy-git-17032011/policy/modules/kernel/files.if	2011-02-22 18:50:44.460551925 +0100
> > +++ refpolicy-git-17032011-restorecon/policy/modules/kernel/files.if	2011-03-19 16:21:01.701636861 +0100
> > @@ -4425,7 +4425,28 @@ interface(`files_relabelfrom_usr_files',
> >  
> >  ########################################
> >  ## <summary>
> > -##	Read symbolic links in /usr.
> > +##	Read symbolic links with type
> > +##	bin_t (usually located in /bin,
> > +##	/sbin, /usr/bin and /usr/sbin).
> > +## </summary>
> > +## <param name="domain">
> > +##	<summary>
> > +##	Domain allowed access.
> > +##	</summary>
> > +## </param>
> > +#
> > +interface(`files_read_bin_symlinks',`
> 
> 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

Yes, apart from the duplicate interface, the restorecon symbolic link is
created by the original Makefile from policycoreutils. It's fine to me
if setfiles is just copied off instead of linked.

Regards,

Guido

[refpolicy] restorecon needs to read bin_t symlinks

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

[refpolicy] restorecon needs to read bin_t symlinks

[Guido Trentalancia]

On Sat, 19/03/2011 at 18.12 +0100, Guido Trentalancia wrote:
> On Sat, 19/03/2011 at 16.51 +0100, Dominick Grift wrote:
> > On 03/19/2011 04:45 PM, Guido Trentalancia wrote:
> > > Hello !
> > > 
> > > I have recently started to experience AVC denials due to restorecon
> > > trying to read bin_t symbolic links. It is not entirely clear to me what
> > > is triggering this, since everything has been working fine for a long
> > > time.
> > > 
> > > In any case, I had to apply the following patch on my system (and I am
> > > still asking myself why not files_read_all_symlinks then ?):
> > > 
> > > diff -pruN refpolicy-git-17032011/policy/modules/kernel/files.if refpolicy-git-17032011-restorecon/policy/modules/kernel/files.if
> > > --- refpolicy-git-17032011/policy/modules/kernel/files.if	2011-02-22 18:50:44.460551925 +0100
> > > +++ refpolicy-git-17032011-restorecon/policy/modules/kernel/files.if	2011-03-19 16:21:01.701636861 +0100
> > > @@ -4425,7 +4425,28 @@ interface(`files_relabelfrom_usr_files',
> > >  
> > >  ########################################
> > >  ## <summary>
> > > -##	Read symbolic links in /usr.
> > > +##	Read symbolic links with type
> > > +##	bin_t (usually located in /bin,
> > > +##	/sbin, /usr/bin and /usr/sbin).
> > > +## </summary>
> > > +## <param name="domain">
> > > +##	<summary>
> > > +##	Domain allowed access.
> > > +##	</summary>
> > > +## </param>
> > > +#
> > > +interface(`files_read_bin_symlinks',`
> > 
> > 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
> 
> Yes, apart from the duplicate interface, the restorecon symbolic link is
> created by the original Makefile from policycoreutils. It's fine to me
> if setfiles is just copied off instead of linked.

Actually it has nothing to do with restorecon being a symbolic link to
the setfiles binary.

Without the "read" capability restorecon is not able to relabel the
target file. This is quite bad as we could have non-standard things such
as:

ls -al /bin/example_executable
lrwxrwxrwx. root root /bin/example_executable
-> /opt/example/example_application

and example_application never getting relabelled as bin_t (but instead
falling back to usr_t).

If "file_type:lnk_file read" does not imply the ability to read the
actual content of the target file then perhaps we could even use
files_read_all_symlinks().

And by the way setfiles/restorecon might also need
logging_send_audit_msgs(setfiles_t).

Regards,

Guido

[refpolicy] restorecon needs to read bin_t symlinks

[Sven Vermeulen]

On Sat, Mar 19, 2011 at 08:54:46PM +0100, Guido Trentalancia wrote:
> Actually it has nothing to do with restorecon being a symbolic link to
> the setfiles binary.
> 
> Without the "read" capability restorecon is not able to relabel the
> target file. This is quite bad as we could have non-standard things such
> as:
> 
> ls -al /bin/example_executable
> lrwxrwxrwx. root root /bin/example_executable
> -> /opt/example/example_application
> 
> and example_application never getting relabelled as bin_t (but instead
> falling back to usr_t).

Actually, I would imagine we don't want restorecon to follow symlinks to
relabel the target files. If we did, then in your example both usr_t and
bin_t for /opt/example/example_application are valid labels (which isn't
possible).

restorecon /bin/example_executable
restorecon /opt/example/example_application

The statements would switch the label. A full filesystem relabel, which is
sometimes touted to be a good solution in case of problems, is in this case
undecisive as we don't know in which order the files are scanned.

Wkr,
	Sven Vermeulen

[refpolicy] restorecon needs to read bin_t symlinks

[Guido Trentalancia]

On Sat, 19/03/2011 at 21.05 +0100, Sven Vermeulen wrote:
> On Sat, Mar 19, 2011 at 08:54:46PM +0100, Guido Trentalancia wrote:
> > Actually it has nothing to do with restorecon being a symbolic link to
> > the setfiles binary.
> > 
> > Without the "read" capability restorecon is not able to relabel the
> > target file. This is quite bad as we could have non-standard things such
> > as:
> > 
> > ls -al /bin/example_executable
> > lrwxrwxrwx. root root /bin/example_executable
> > -> /opt/example/example_application
> > 
> > and example_application never getting relabelled as bin_t (but instead
> > falling back to usr_t).
> 
> Actually, I would imagine we don't want restorecon to follow symlinks to
> relabel the target files. If we did, then in your example both usr_t and
> bin_t for /opt/example/example_application are valid labels (which isn't
> possible).
> 
> restorecon /bin/example_executable
> restorecon /opt/example/example_application
> 
> The statements would switch the label. A full filesystem relabel, which is
> sometimes touted to be a good solution in case of problems, is in this case
> undecisive as we don't know in which order the files are scanned.

With "lnk_file:read" it just relabels the target file according to the
(unique system-wide) file context definitions. So there won't be
indecision.

My example was wrong (that would never happen). Do we want
setfiles/restorecon to follow symbolic links and relabel the target ?

Regards,

Guido

[refpolicy] restorecon needs to read bin_t symlinks

[Guido Trentalancia]

On Sat, 19/03/2011 at 21.05 +0100, Sven Vermeulen wrote:
> On Sat, Mar 19, 2011 at 08:54:46PM +0100, Guido Trentalancia wrote:
> > Actually it has nothing to do with restorecon being a symbolic link to
> > the setfiles binary.
> > 
> > Without the "read" capability restorecon is not able to relabel the
> > target file. This is quite bad as we could have non-standard things such
> > as:
> > 
> > ls -al /bin/example_executable
> > lrwxrwxrwx. root root /bin/example_executable
> > -> /opt/example/example_application
> > 
> > and example_application never getting relabelled as bin_t (but instead
> > falling back to usr_t).
> 
> Actually, I would imagine we don't want restorecon to follow symlinks to
> relabel the target files. If we did, then in your example both usr_t and
> bin_t for /opt/example/example_application are valid labels (which isn't
> possible).
> 
> restorecon /bin/example_executable
> restorecon /opt/example/example_application
> 
> The statements would switch the label. A full filesystem relabel, which is
> sometimes touted to be a good solution in case of problems, is in this case
> undecisive as we don't know in which order the files are scanned.

The example was not just wrong, it was mad. If that was really
happening, then an unprivileged user could potentially relabel the
entire filesystem at will by just creating symbolic links into his/her
home directory, labelling them at will and running the relabelling tool
on each of those links. Clearly (and fortunately) the label is not taken
from the source file !

However, the conclusion is either we want setfiles/restorecon to relabel
the target or we want to "dontaudit" read operations on symbolic links.
I am quite sure we don't want the logs flooded.

Regards,

Guido

[refpolicy] restorecon needs to read bin_t symlinks

[Christopher J. PeBenito]

On 03/19/11 16:38, Guido Trentalancia wrote:
> On Sat, 19/03/2011 at 21.05 +0100, Sven Vermeulen wrote:
>> On Sat, Mar 19, 2011 at 08:54:46PM +0100, Guido Trentalancia wrote:
>>> Actually it has nothing to do with restorecon being a symbolic link to
>>> the setfiles binary.
>>>
>>> Without the "read" capability restorecon is not able to relabel the
>>> target file. This is quite bad as we could have non-standard things such
>>> as:
>>>
>>> ls -al /bin/example_executable
>>> lrwxrwxrwx. root root /bin/example_executable
>>> -> /opt/example/example_application
>>>
>>> and example_application never getting relabelled as bin_t (but instead
>>> falling back to usr_t).
>>
>> Actually, I would imagine we don't want restorecon to follow symlinks to
>> relabel the target files. If we did, then in your example both usr_t and
>> bin_t for /opt/example/example_application are valid labels (which isn't
>> possible).
>>
>> restorecon /bin/example_executable
>> restorecon /opt/example/example_application
>>
>> The statements would switch the label. A full filesystem relabel, which is
>> sometimes touted to be a good solution in case of problems, is in this case
>> undecisive as we don't know in which order the files are scanned.
> 
> The example was not just wrong, it was mad. If that was really
> happening, then an unprivileged user could potentially relabel the
> entire filesystem at will by just creating symbolic links into his/her
> home directory, labelling them at will and running the relabelling tool
> on each of those links. Clearly (and fortunately) the label is not taken
> from the source file !
> 
> However, the conclusion is either we want setfiles/restorecon to relabel
> the target or we want to "dontaudit" read operations on symbolic links.
> I am quite sure we don't want the logs flooded.

Restorecon should not be following symlinks.  If it is labeling the
target with the label of the link, that is a bug and needs to go to the
SELinux list.  I looked at the source, and all I see is usage of
lsetfilecon() and lgetfilecon(), so it shouldn't be following symlinks.


-- 
Chris PeBenito
Tresys Technology, LLC
www.tresys.com | oss.tresys.com

[refpolicy] restorecon needs to read bin_t symlinks

[Daniel J Walsh]

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