I am concerned about putting genhomedircon changes in libsemanage into Fedora 8.

I am concerned about putting genhomedircon changes in libsemanage into Fedora 8.

[Daniel J Walsh]

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

I may hold off on this so we can get a full Rawhide cycle on it.
genhomedircon has many corner cases and do not want to risk blowing F-8
now that we are at Feature Freeze.
All the rest of the patches have been integrated.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iD8DBQFGztKCrlYvE4MpobMRAjjPAKCPcYgyrJRjqxx06ppqxLxxuWGqnwCeJOLU
eTMWKakqHN5ZNehfgn27tI8=
=3qy6
-----END PGP SIGNATURE-----

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: I am concerned about putting genhomedircon changes in libsemanage into Fedora 8.

[Daniel J Walsh]

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

Daniel J Walsh wrote:
> I may hold off on this so we can get a full Rawhide cycle on it.
> genhomedircon has many corner cases and do not want to risk blowing F-8
> now that we are at Feature Freeze.
> All the rest of the patches have been integrated.

- --
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov
with
the words "unsubscribe selinux" without quotes as the message.


The genhomedircon replacement is broken in libsemanage.  It is
generating invalid file context.  The python version verified the
file context it was creating were valid before assiging them.  This is
resulting in Fedora Core 8 not being able to autorelabel


 /sbin/fixfiles restore
/etc/selinux/targeted/contexts/files/file_contexts.homedirs:  line 26
has invalid context user_u:object_r:user_gconf_home_t:s0
/etc/selinux/targeted/contexts/files/file_contexts.homedirs:  line 51
has invalid context user_u:object_r:user_gconf_tmp_t:s0
/etc/selinux/targeted/contexts/files/file_contexts.homedirs:  line 60
has invalid context mytuser_u:object_r:mytuser_gnome_home_t:s0
/etc/selinux/targeted/contexts/files/file_contexts.homedirs:  line 63
has invalid context mytuser_u:object_r:httpd_mytuser_content_t:s0
/etc/selinux/targeted/contexts/files/file_contexts.homedirs:  line 64
has invalid context mytuser_u:object_r:mytuser_home_ssh_t:s0
/etc/selinux/targeted/contexts/files/file_contexts.homedirs:  line 65
has invalid context mytuser_u:object_r:mytuser_uml_rw_t:s0
/etc/selinux/targeted/contexts/files/file_contexts.homedirs:  line 66
has invalid context mytuser_u:object_r:mytuser_mozilla_home_t:s0
/etc/selinux/targeted/contexts/files/file_contexts.homedirs:  line 67
has invalid context mytuser_u:object_r:mytuser_xauth_home_t:s0
/etc/selinux/targeted/contexts/files/file_contexts.homedirs:  line 68
has invalid context mytuser_u:object_r:mytuser_fonts_t:s0
Exiting after 10 errors.

mytuser does not execute the mozilla_per_role_template to these types
are not valid.  genhomedircon is only supposed to generate valid context.

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

iD8DBQFG+mYfrlYvE4MpobMRApsVAJ0QZKye8RZl+5To2e+5Y/XRx4CO/gCgxi01
U7EXmMgIuDtsH81KGKKhpeI=
=pcqC
-----END PGP SIGNATURE-----

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: I am concerned about putting genhomedircon changes in libsemanage into Fedora 8.

[Joshua Brindle]

Daniel J Walsh wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Daniel J Walsh wrote:
>   
>> I may hold off on this so we can get a full Rawhide cycle on it.
>> genhomedircon has many corner cases and do not want to risk blowing F-8
>> now that we are at Feature Freeze.
>> All the rest of the patches have been integrated.
>
>
>
> The genhomedircon replacement is broken in libsemanage.  It is
> generating invalid file context.  The python version verified the
> file context it was creating were valid before assiging them.  This is
> resulting in Fedora Core 8 not being able to autorelabel
>
>   

The python version did the wrong thing entirely. It validated the 
contexts against the running policy in the kernel, which breaks when you 
try to do an operation on another store. Also since we moved 
genhomedircon inside of libsemanage the new policy isn't even loaded yet 
so we can't validate against the kernel (or the new types added by the 
module being added would be 'invalid'). The only real way to validate 
the contexts now would be to load the newly generated policy into the 
libsepol security server and to the context validations on it.

This would work, it would just take extra time at module load time. It 
seems like the real problem is that the invalid contexts are being 
generated in the first place, relying on genhomedircon to sanity check 
your file contexts seems like you are punting the problem.

>  /sbin/fixfiles restore
> /etc/selinux/targeted/contexts/files/file_contexts.homedirs:  line 26
> has invalid context user_u:object_r:user_gconf_home_t:s0
> /etc/selinux/targeted/contexts/files/file_contexts.homedirs:  line 51
> has invalid context user_u:object_r:user_gconf_tmp_t:s0
> /etc/selinux/targeted/contexts/files/file_contexts.homedirs:  line 60
> has invalid context mytuser_u:object_r:mytuser_gnome_home_t:s0
> /etc/selinux/targeted/contexts/files/file_contexts.homedirs:  line 63
> has invalid context mytuser_u:object_r:httpd_mytuser_content_t:s0
> /etc/selinux/targeted/contexts/files/file_contexts.homedirs:  line 64
> has invalid context mytuser_u:object_r:mytuser_home_ssh_t:s0
> /etc/selinux/targeted/contexts/files/file_contexts.homedirs:  line 65
> has invalid context mytuser_u:object_r:mytuser_uml_rw_t:s0
> /etc/selinux/targeted/contexts/files/file_contexts.homedirs:  line 66
> has invalid context mytuser_u:object_r:mytuser_mozilla_home_t:s0
> /etc/selinux/targeted/contexts/files/file_contexts.homedirs:  line 67
> has invalid context mytuser_u:object_r:mytuser_xauth_home_t:s0
> /etc/selinux/targeted/contexts/files/file_contexts.homedirs:  line 68
> has invalid context mytuser_u:object_r:mytuser_fonts_t:s0
> Exiting after 10 errors.
>
> mytuser does not execute the mozilla_per_role_template to these types
> are not valid.  genhomedircon is only supposed to generate valid context.
>
>   



--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: I am concerned about putting genhomedircon changes in libsemanage into Fedora 8.

[Stephen Smalley]

On Wed, 2007-09-26 at 10:47 -0400, Joshua Brindle wrote:
> Daniel J Walsh wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> > Daniel J Walsh wrote:
> >   
> >> I may hold off on this so we can get a full Rawhide cycle on it.
> >> genhomedircon has many corner cases and do not want to risk blowing F-8
> >> now that we are at Feature Freeze.
> >> All the rest of the patches have been integrated.
> >
> >
> >
> > The genhomedircon replacement is broken in libsemanage.  It is
> > generating invalid file context.  The python version verified the
> > file context it was creating were valid before assiging them.  This is
> > resulting in Fedora Core 8 not being able to autorelabel
> >
> >   
> 
> The python version did the wrong thing entirely. It validated the 
> contexts against the running policy in the kernel, which breaks when you 
> try to do an operation on another store. Also since we moved 
> genhomedircon inside of libsemanage the new policy isn't even loaded yet 
> so we can't validate against the kernel (or the new types added by the 
> module being added would be 'invalid'). The only real way to validate 
> the contexts now would be to load the newly generated policy into the 
> libsepol security server and to the context validations on it.

i.e. sepol_set_policydb_from_file() on the policy, and then
sepol_check_context() on the contexts, as is done by setfiles -c.

> This would work, it would just take extra time at module load time. It 
> seems like the real problem is that the invalid contexts are being 
> generated in the first place, relying on genhomedircon to sanity check 
> your file contexts seems like you are punting the problem.

I think the problem is that the templating mechanism isn't sufficiently
flexible; the per-role contexts aren't necessarily valid for all cases.

In any event, this is a regression between the old genhomedircon and the
libsemanage reimplementation and should have been called out as a change
in behavior in the patch set, even if the old behavior was flawed.

So I guess Dan needs to stay with the old genhomedircon and libsemanage
for Fedora 8.

-- 
Stephen Smalley
National Security Agency


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: I am concerned about putting genhomedircon changes in libsemanage into Fedora 8.

[Stephen Smalley]

On Wed, 2007-09-26 at 10:52 -0400, Stephen Smalley wrote:
> On Wed, 2007-09-26 at 10:47 -0400, Joshua Brindle wrote:
> > Daniel J Walsh wrote:
> > > -----BEGIN PGP SIGNED MESSAGE-----
> > > Hash: SHA1
> > >
> > > Daniel J Walsh wrote:
> > >   
> > >> I may hold off on this so we can get a full Rawhide cycle on it.
> > >> genhomedircon has many corner cases and do not want to risk blowing F-8
> > >> now that we are at Feature Freeze.
> > >> All the rest of the patches have been integrated.
> > >
> > >
> > >
> > > The genhomedircon replacement is broken in libsemanage.  It is
> > > generating invalid file context.  The python version verified the
> > > file context it was creating were valid before assiging them.  This is
> > > resulting in Fedora Core 8 not being able to autorelabel
> > >
> > >   
> > 
> > The python version did the wrong thing entirely. It validated the 
> > contexts against the running policy in the kernel, which breaks when you 
> > try to do an operation on another store. Also since we moved 
> > genhomedircon inside of libsemanage the new policy isn't even loaded yet 
> > so we can't validate against the kernel (or the new types added by the 
> > module being added would be 'invalid'). The only real way to validate 
> > the contexts now would be to load the newly generated policy into the 
> > libsepol security server and to the context validations on it.
> 
> i.e. sepol_set_policydb_from_file() on the policy, and then
> sepol_check_context() on the contexts, as is done by setfiles -c.

Actually, for new code, should use sepol_context_check(), as that takes
the handle and the policydb as inputs.

> > This would work, it would just take extra time at module load time. It 
> > seems like the real problem is that the invalid contexts are being 
> > generated in the first place, relying on genhomedircon to sanity check 
> > your file contexts seems like you are punting the problem.
> 
> I think the problem is that the templating mechanism isn't sufficiently
> flexible; the per-role contexts aren't necessarily valid for all cases.
> 
> In any event, this is a regression between the old genhomedircon and the
> libsemanage reimplementation and should have been called out as a change
> in behavior in the patch set, even if the old behavior was flawed.
> 
> So I guess Dan needs to stay with the old genhomedircon and libsemanage
> for Fedora 8.

-- 
Stephen Smalley
National Security Agency


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: I am concerned about putting genhomedircon changes in libsemanage into Fedora 8.

[Karl MacMillan]

On Wed, 2007-09-26 at 10:47 -0400, Joshua Brindle wrote:
> Daniel J Walsh wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> > Daniel J Walsh wrote:
> >   
> >> I may hold off on this so we can get a full Rawhide cycle on it.
> >> genhomedircon has many corner cases and do not want to risk blowing F-8
> >> now that we are at Feature Freeze.
> >> All the rest of the patches have been integrated.
> >
> >
> >
> > The genhomedircon replacement is broken in libsemanage.  It is
> > generating invalid file context.  The python version verified the
> > file context it was creating were valid before assiging them.  This is
> > resulting in Fedora Core 8 not being able to autorelabel
> >
> >   
> 
> The python version did the wrong thing entirely. It validated the 
> contexts against the running policy in the kernel, which breaks when you 
> try to do an operation on another store. Also since we moved 
> genhomedircon inside of libsemanage the new policy isn't even loaded yet 
> so we can't validate against the kernel (or the new types added by the 
> module being added would be 'invalid'). The only real way to validate 
> the contexts now would be to load the newly generated policy into the 
> libsepol security server and to the context validations on it.
> 
> This would work, it would just take extra time at module load time. It 
> seems like the real problem is that the invalid contexts are being 
> generated in the first place, relying on genhomedircon to sanity check 
> your file contexts seems like you are punting the problem.
> 

Perhaps - but it is a significant change in behavior and reworking all
of the policies is going to be difficult or impossible.

Karl


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: I am concerned about putting genhomedircon changes in libsemanage into Fedora 8.

[Daniel J Walsh]

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

Joshua Brindle wrote:
> Daniel J Walsh wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> Daniel J Walsh wrote:
>>  
>>> I may hold off on this so we can get a full Rawhide cycle on it.
>>> genhomedircon has many corner cases and do not want to risk blowing F-8
>>> now that we are at Feature Freeze.
>>> All the rest of the patches have been integrated.
>>
>>
>>
>> The genhomedircon replacement is broken in libsemanage.  It is
>> generating invalid file context.  The python version verified the
>> file context it was creating were valid before assiging them.  This is
>> resulting in Fedora Core 8 not being able to autorelabel
>>
>>   
> 
> The python version did the wrong thing entirely. It validated the
> contexts against the running policy in the kernel, which breaks when you
> try to do an operation on another store. Also since we moved
> genhomedircon inside of libsemanage the new policy isn't even loaded yet
> so we can't validate against the kernel (or the new types added by the
> module being added would be 'invalid'). The only real way to validate
> the contexts now would be to load the newly generated policy into the
> libsepol security server and to the context validations on it.
> 

> This would work, it would just take extra time at module load time. It
> seems like the real problem is that the invalid contexts are being
> generated in the first place, relying on genhomedircon to sanity check
> your file contexts seems like you are punting the problem.
> 
Whether it did the wrong thing or not, the current functionality is more
broken.  You can not relabel with the current policy.  If SEManage could
automatically generate the homedir context based off the available
homedirectory context great.  Otherwise the only way we can do it is to
generate all the homedir context and then figure out which ones are
valid for this user.

Lets fix the short time problem, by putting in the simple check the
currently running kernel.   If semanage loads the policy before
generating the homedir context, it should work fine. It is the best we
can do in the short run. And it works in the real world for now.

If we want to invalidate this on -s TYPE not matching fine.  Once we
have patches that will validate on the installed context versus the one
loaded into the kernel.  We have other problems that I want to bring up
in other email chains.  About handling the installation of modules and
running of semanage when selinux is disabled.

For now we are in the Deep Freeze of Fedora 8 and I can't relabel
because of libsemanage/genhomedircon
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iD8DBQFG+nVyrlYvE4MpobMRAoABAJ9im0eCkD2estiweUrj7tbC48WPNgCguLrJ
4yjcaWIZuUT01vCM+4cAJAQ=
=RKGY
-----END PGP SIGNATURE-----

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: I am concerned about putting genhomedircon changes in libsemanage into Fedora 8.

[Joshua Brindle]

Daniel J Walsh wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Joshua Brindle wrote:
>   
>> Daniel J Walsh wrote:
>>     
>>> -----BEGIN PGP SIGNED MESSAGE-----
>>> Hash: SHA1
>>>
>>> Daniel J Walsh wrote:
>>>  
>>>       
>>>> I may hold off on this so we can get a full Rawhide cycle on it.
>>>> genhomedircon has many corner cases and do not want to risk blowing F-8
>>>> now that we are at Feature Freeze.
>>>> All the rest of the patches have been integrated.
>>>>         
>>>
>>> The genhomedircon replacement is broken in libsemanage.  It is
>>> generating invalid file context.  The python version verified the
>>> file context it was creating were valid before assiging them.  This is
>>> resulting in Fedora Core 8 not being able to autorelabel
>>>
>>>   
>>>       
>> The python version did the wrong thing entirely. It validated the
>> contexts against the running policy in the kernel, which breaks when you
>> try to do an operation on another store. Also since we moved
>> genhomedircon inside of libsemanage the new policy isn't even loaded yet
>> so we can't validate against the kernel (or the new types added by the
>> module being added would be 'invalid'). The only real way to validate
>> the contexts now would be to load the newly generated policy into the
>> libsepol security server and to the context validations on it.
>>
>>     
>
>   
>> This would work, it would just take extra time at module load time. It
>> seems like the real problem is that the invalid contexts are being
>> generated in the first place, relying on genhomedircon to sanity check
>> your file contexts seems like you are punting the problem.
>>
>>     
> Whether it did the wrong thing or not, the current functionality is more
> broken.  You can not relabel with the current policy.  If SEManage could
> automatically generate the homedir context based off the available
> homedirectory context great.  Otherwise the only way we can do it is to
> generate all the homedir context and then figure out which ones are
> valid for this user.
>
> Lets fix the short time problem, by putting in the simple check the
> currently running kernel.   If semanage loads the policy before
> generating the homedir context, it should work fine. It is the best we
> can do in the short run. And it works in the real world for now.
>
> If we want to invalidate this on -s TYPE not matching fine.  Once we
> have patches that will validate on the installed context versus the one
> loaded into the kernel.  We have other problems that I want to bring up
> in other email chains.  About handling the installation of modules and
> running of semanage when selinux is disabled.
>
> For now we are in the Deep Freeze of Fedora 8 and I can't relabel
> because of libsemanage/genhomedircon
>   

We can add the checking back asap, the best way to do it is by loading 
the policy we just generated and validating against it in userspace (we 
can't validate against the kernel since genhomedircon now runs within 
the transaction and the new policy won't be loaded).


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: I am concerned about putting genhomedircon changes in libsemanage into Fedora 8.

[Stephen Smalley]

On Wed, 2007-09-26 at 11:10 -0400, Joshua Brindle wrote:
> Daniel J Walsh wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> > Joshua Brindle wrote:
> >   
> >> Daniel J Walsh wrote:
> >>     
> >>> -----BEGIN PGP SIGNED MESSAGE-----
> >>> Hash: SHA1
> >>>
> >>> Daniel J Walsh wrote:
> >>>  
> >>>       
> >>>> I may hold off on this so we can get a full Rawhide cycle on it.
> >>>> genhomedircon has many corner cases and do not want to risk blowing F-8
> >>>> now that we are at Feature Freeze.
> >>>> All the rest of the patches have been integrated.
> >>>>         
> >>>
> >>> The genhomedircon replacement is broken in libsemanage.  It is
> >>> generating invalid file context.  The python version verified the
> >>> file context it was creating were valid before assiging them.  This is
> >>> resulting in Fedora Core 8 not being able to autorelabel
> >>>
> >>>   
> >>>       
> >> The python version did the wrong thing entirely. It validated the
> >> contexts against the running policy in the kernel, which breaks when you
> >> try to do an operation on another store. Also since we moved
> >> genhomedircon inside of libsemanage the new policy isn't even loaded yet
> >> so we can't validate against the kernel (or the new types added by the
> >> module being added would be 'invalid'). The only real way to validate
> >> the contexts now would be to load the newly generated policy into the
> >> libsepol security server and to the context validations on it.
> >>
> >>     
> >
> >   
> >> This would work, it would just take extra time at module load time. It
> >> seems like the real problem is that the invalid contexts are being
> >> generated in the first place, relying on genhomedircon to sanity check
> >> your file contexts seems like you are punting the problem.
> >>
> >>     
> > Whether it did the wrong thing or not, the current functionality is more
> > broken.  You can not relabel with the current policy.  If SEManage could
> > automatically generate the homedir context based off the available
> > homedirectory context great.  Otherwise the only way we can do it is to
> > generate all the homedir context and then figure out which ones are
> > valid for this user.
> >
> > Lets fix the short time problem, by putting in the simple check the
> > currently running kernel.   If semanage loads the policy before
> > generating the homedir context, it should work fine. It is the best we
> > can do in the short run. And it works in the real world for now.
> >
> > If we want to invalidate this on -s TYPE not matching fine.  Once we
> > have patches that will validate on the installed context versus the one
> > loaded into the kernel.  We have other problems that I want to bring up
> > in other email chains.  About handling the installation of modules and
> > running of semanage when selinux is disabled.
> >
> > For now we are in the Deep Freeze of Fedora 8 and I can't relabel
> > because of libsemanage/genhomedircon
> >   
> 
> We can add the checking back asap, the best way to do it is by loading 
> the policy we just generated and validating against it in userspace (we 
> can't validate against the kernel since genhomedircon now runs within 
> the transaction and the new policy won't be loaded).

Looks like semanage_direct_commit() can just pass the in-memory expanded
policydb (out) to semanage_install_sandbox() and have it pass it down to
semanage_genhomedircon(), at which point it can be put in the
genhomedir_settings structure for further propagation to wherever we
need to do the sepol_context_check().

But the current genhomedircon.c code doesn't appear to parse the record
anywhere, just does string replacement on the entire line and then
writes it out.

fcontext_parse over in fcontexts_file.c does the parsing of
file_contexts.local, called by dbase_file_cache as the ->parse method.
semanage_fcontext_validate_local in fcontexts_local.c does validation of
those entries.  Not sure how much of that we can re-use for this
purpose.

-- 
Stephen Smalley
National Security Agency


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: I am concerned about putting genhomedircon changes in libsemanage into Fedora 8.

[Stephen Smalley]

On Wed, 2007-09-26 at 11:06 -0400, Daniel J Walsh wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Joshua Brindle wrote:
> > Daniel J Walsh wrote:
> >> -----BEGIN PGP SIGNED MESSAGE-----
> >> Hash: SHA1
> >>
> >> Daniel J Walsh wrote:
> >>  
> >>> I may hold off on this so we can get a full Rawhide cycle on it.
> >>> genhomedircon has many corner cases and do not want to risk blowing F-8
> >>> now that we are at Feature Freeze.
> >>> All the rest of the patches have been integrated.
> >>
> >>
> >>
> >> The genhomedircon replacement is broken in libsemanage.  It is
> >> generating invalid file context.  The python version verified the
> >> file context it was creating were valid before assiging them.  This is
> >> resulting in Fedora Core 8 not being able to autorelabel
> >>
> >>   
> > 
> > The python version did the wrong thing entirely. It validated the
> > contexts against the running policy in the kernel, which breaks when you
> > try to do an operation on another store. Also since we moved
> > genhomedircon inside of libsemanage the new policy isn't even loaded yet
> > so we can't validate against the kernel (or the new types added by the
> > module being added would be 'invalid'). The only real way to validate
> > the contexts now would be to load the newly generated policy into the
> > libsepol security server and to the context validations on it.
> > 
> 
> > This would work, it would just take extra time at module load time. It
> > seems like the real problem is that the invalid contexts are being
> > generated in the first place, relying on genhomedircon to sanity check
> > your file contexts seems like you are punting the problem.
> > 
> Whether it did the wrong thing or not, the current functionality is more
> broken.  You can not relabel with the current policy.  If SEManage could
> automatically generate the homedir context based off the available
> homedirectory context great.  Otherwise the only way we can do it is to
> generate all the homedir context and then figure out which ones are
> valid for this user.
> 
> Lets fix the short time problem, by putting in the simple check the
> currently running kernel.   If semanage loads the policy before
> generating the homedir context, it should work fine. It is the best we
> can do in the short run. And it works in the real world for now.
> 
> If we want to invalidate this on -s TYPE not matching fine.  Once we
> have patches that will validate on the installed context versus the one
> loaded into the kernel.  We have other problems that I want to bring up
> in other email chains.  About handling the installation of modules and
> running of semanage when selinux is disabled.
> 
> For now we are in the Deep Freeze of Fedora 8 and I can't relabel
> because of libsemanage/genhomedircon

...so revert to the old libsemanage/genhomedircon, or at least that
particular patch?

-- 
Stephen Smalley
National Security Agency


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.