From: deleriux@airattack-central.com (Matthew Ife)
Date: Wed, 06 Jul 2011 19:24:04 +0100
Subject: [refpolicy] [Fwd: SSSD Local Auth and SELinux support]
In-Reply-To: <4E1467C9.2090403@tresys.com>
References: <1309897035.29086.4.camel@home.localdomain>
	<4E1467C9.2090403@tresys.com>
Message-ID: <1309976645.27109.9.camel@home.localdomain>
To: refpolicy@oss.tresys.com
List-Id: refpolicy.oss.tresys.com

On Wed, 2011-07-06 at 09:48 -0400, Christopher J. PeBenito wrote:
> On 07/05/11 16:17, Matthew Ife wrote:
> > This is an email I forwarded to the F15 selinux policy mailing list.
> > 
> > As suggested, I forward the email and the attached patch which attempts
> > to resolve what I discussed.
> > 
> > If you have any questions please let me know. This was a patch applied
> > to refpolicy.

> If we're looking to go down this road, then we have to consider other
> sources of authentication, such as nis, kerberos, and samba/winbind.
That has also crossed my mind as being a useful idea.

> This may cause problems with package managers trying to
> install/initialize the database for the first time, which is a concern.
> 
Potentially and that would need to be tested for. SSSD doesnt need it as
it generates the the files it needs upon startup. The worst case
scenario here is we give the types that need it the access needed for
package managers to do what they need to.
I do not think it would be a good idea to do all things we want to label
as auth files in one fell swoop, big services like winbind and kerberos
need testing for at least the majority of use-cases.

> There are a few problems (see inline):
...
...
> >  init_use_fds(sxid_t)
> > diff --git a/policy/modules/kernel/files.if b/policy/modules/kernel/files.if
> > index ff006ea..e1cd45f 100644
> > --- a/policy/modules/kernel/files.if
> > +++ b/policy/modules/kernel/files.if
> > @@ -49,6 +49,7 @@
> >  ##		<li>init_script_file()</li>
> >  ##		<li>init_script_domain()</li>
> >  ##		<li>init_system_domain()</li>
> > +##              <li>files_auth_file()</li>
> 
> Please use tabs.
I'll correct that.

> >  ##		<li>files_config_files()</li>
> >  ##		<li>files_lock_file()</li>
> >  ##		<li>files_mountpoint()</li>
> > @@ -215,6 +216,33 @@ interface(`files_pid_file',`
> >  
> >  ########################################
> >  ## <summary>
> > +##      Make the specified type a
> > +##      authentication file.
> > +## </summary>
> > +## <desc>
> > +##      <p>
> > +##      Make the specified type an authentication file.
> > +##      This will also make the type usable for security files, making
> > +##      calls to files_security_file() redundant.
> > +##      </p>
> > +## </desc>
> 
> I don't agree with this assessment.  Security files are a superset of
> authentication files.  In fact, I think the interface should likely call
> files_security_file().  Additionally, this interface is in the wrong
> module, it should be in the authlogin module, otherwise those interfaces
> would be breaking encapsulation.

Not sure what you mean here. Perhaps I am getting the wrong idea of its
meaning. The interface does call files_security_file (thus the idea of
calling it yourself is redundant). Is this not what this is meant to
mean? Regarding the interface itself - I wasn't super certain whether or
not it went in there since files_security_file went in there. I can put
it in the authlogin interface though easily enough.


<the stuff in various interface files>
> None of these interface renames are permissible, as it breaks
> compatibility.  You need to add new interfaces, and deprecateto the
> "except_shadow" interfaces (see libs_use_lib_files() for an example).
I'll look into that.


> >  ########################################
> > diff --git a/policy/modules/system/authlogin.te b/policy/modules/system/authlogin.te
> > index b7a5f00..00b9e8d 100644
> > --- a/policy/modules/system/authlogin.te
> > +++ b/policy/modules/system/authlogin.te
> > @@ -1,10 +1,9 @@
> > -policy_module(authlogin, 2.2.1)
> > -
> I don't know why you would be doing this.
Nor do I, must have been a random keyboard burst. That shouldn't be
there.