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)
-----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-----
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
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
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
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
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
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
http://www.tresys.com | oss.tresys.com