From: guido@trentalancia.com (Guido Trentalancia)
Date: Sat, 19 Mar 2011 20:54:46 +0100
Subject: [refpolicy] restorecon needs to read bin_t symlinks
In-Reply-To: <1300554772.3034.28.camel@tesla.lan>
References: <1300549506.3034.24.camel@tesla.lan>
	<4D84D11C.5090909@gmail.com>  <1300554772.3034.28.camel@tesla.lan>
Message-ID: <1300564486.3101.14.camel@tesla.lan>
To: refpolicy@oss.tresys.com
List-Id: refpolicy.oss.tresys.com

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