[patch 0/4] libsemanage: genhomedircon replacement

[patch 0/4] libsemanage: genhomedircon replacement

[tmiller]

This replaces genhomedircon with equivalent functionality in libsemanage. The
homedir_template is also no longer installed, this leaves some unused path
functions in libselinux but removing those would break the ABI.

This does the same things that genhomedircon did though some seemed strange,
like removing /sbin/nologin from the list of valid shells, presumably to keep
ftp users and such from getting file contexts generated for them, I'm not sure
how valid the assumption is but we didn't want to change the functionality of
genhomedircon in this patch set.

This patch also generalizes some functionality of genhomedircon so that it can
be extended in the future (ex: for policy server user contexts)

The first patch does some cleanup to make way for the new genhomedircon.

The second patch adds genhomedircon.c and utilities.c to libsemanage. It calls
the code in genhomedircon.c from semanage_store.c and removes the prior call
to genhomedircon. This version uses libustr for string manipulations, which
creates an external dependency available in the development yum repository.
There is, however, an option to embed the ustr code directly into the library
and eliminate the runtime dependency.

The third patch is a set of tests for the new functions in utilities.c.

The final patch removes the old genhomedircon script.

Signed-Off-By: Todd Miller <tmiller@tresys.com>

-- 

--
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: [patch 0/4] libsemanage: genhomedircon replacement

[Karl MacMillan]

On Wed, 2007-08-15 at 16:44 -0400, tmiller@tresys.com wrote:
> This replaces genhomedircon with equivalent functionality in libsemanage. The
> homedir_template is also no longer installed, this leaves some unused path
> functions in libselinux but removing those would break the ABI.
> 

On a higher level, perhaps we should stop doing per-role home
directory labeling at all and therefore remove genhomedircon entirely.
I've been thinking about how to work this on a LDAP based network with
remote home directories and I think the basic conclusion is that
role-based labeling will simply not work (especially if we start
assigning different primary roles to the same user on different systems
with the same remote home directories).

I suggest that we rely on either DAC or separate namespaces to separate
user access to home directories and have one set of types for all home
directories. On systems where you really want SELinux to do the
separation you can use user constraints (which could either acheive the
current role-level separation or user-level separation based on how you
map your SELinux users).

(BTW - most of the above was suggested to me by Dan and Steve in private
concersations).

Thoughts?

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: [patch 0/4] libsemanage: genhomedircon replacement

[Joshua Brindle]

Karl MacMillan wrote:
> On Wed, 2007-08-15 at 16:44 -0400, tmiller@tresys.com wrote:
>> This replaces genhomedircon with equivalent functionality in libsemanage. The
>> homedir_template is also no longer installed, this leaves some unused path
>> functions in libselinux but removing those would break the ABI.
>>
> 
> On a higher level, perhaps we should stop doing per-role home
> directory labeling at all and therefore remove genhomedircon entirely.
> I've been thinking about how to work this on a LDAP based network with
> remote home directories and I think the basic conclusion is that
> role-based labeling will simply not work (especially if we start
> assigning different primary roles to the same user on different systems
> with the same remote home directories).
> 
> I suggest that we rely on either DAC or separate namespaces to separate
> user access to home directories and have one set of types for all home
> directories. On systems where you really want SELinux to do the
> separation you can use user constraints (which could either acheive the
> current role-level separation or user-level separation based on how you
> map your SELinux users).
> 
> (BTW - most of the above was suggested to me by Dan and Steve in private
> concersations).
> 
> Thoughts?

Without genhomedircon how do you expect to be able to label home 
directories with the appropriate MLS levels for the LSPP version of RH?


--
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: [patch 0/4] libsemanage: genhomedircon replacement

[Karl MacMillan]

On Wed, 2007-08-15 at 11:29 -0400, Joshua Brindle wrote:
> Karl MacMillan wrote:
> > On Wed, 2007-08-15 at 16:44 -0400, tmiller@tresys.com wrote:
> >> This replaces genhomedircon with equivalent functionality in libsemanage. The
> >> homedir_template is also no longer installed, this leaves some unused path
> >> functions in libselinux but removing those would break the ABI.
> >>
> > 
> > On a higher level, perhaps we should stop doing per-role home
> > directory labeling at all and therefore remove genhomedircon entirely.
> > I've been thinking about how to work this on a LDAP based network with
> > remote home directories and I think the basic conclusion is that
> > role-based labeling will simply not work (especially if we start
> > assigning different primary roles to the same user on different systems
> > with the same remote home directories).
> > 
> > I suggest that we rely on either DAC or separate namespaces to separate
> > user access to home directories and have one set of types for all home
> > directories. On systems where you really want SELinux to do the
> > separation you can use user constraints (which could either acheive the
> > current role-level separation or user-level separation based on how you
> > map your SELinux users).
> > 
> > (BTW - most of the above was suggested to me by Dan and Steve in private
> > concersations).
> > 
> > Thoughts?
> 
> Without genhomedircon how do you expect to be able to label home 
> directories with the appropriate MLS levels for the LSPP version of RH?
> 

Perhaps it would be better to set it explicitly rather than based on the
user. Either by giving people a way to set MLS file contexts separately
from the type (which might help with MLS customization in general) or
just doing a chcon on the containing home directory and having that be
inherited (and not set on relabel for home directories).

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: [patch 0/4] libsemanage: genhomedircon replacement

[Joshua Brindle]

Karl MacMillan wrote:
> On Wed, 2007-08-15 at 11:29 -0400, Joshua Brindle wrote:
>> Karl MacMillan wrote:
>>> On Wed, 2007-08-15 at 16:44 -0400, tmiller@tresys.com wrote:
>>>> This replaces genhomedircon with equivalent functionality in
>>>> libsemanage. The homedir_template is also no longer installed, this
>>>> leaves some unused path functions in libselinux but
> removing those would break the ABI.
>>>> 
>>> 
>>> On a higher level, perhaps we should stop doing per-role home
>>> directory labeling at all and therefore remove genhomedircon
>>> entirely. I've been thinking about how to work this on a LDAP based
>>> network with remote home directories and I think the basic
>>> conclusion is that role-based labeling will simply not work
>>> (especially if we start assigning different primary roles to the
>>> same user on different systems with the same remote home
>>> directories). 
>>> 
>>> I suggest that we rely on either DAC or separate namespaces to
>>> separate user access to home directories and have one set of types
>>> for all home directories. On systems where you really want SELinux
>>> to do the separation you can use user constraints (which could
>>> either acheive the current role-level separation or user-level
>>> separation based on how you map your SELinux users).
>>> 
>>> (BTW - most of the above was suggested to me by Dan and Steve in
>>> private concersations). 
>>> 
>>> Thoughts?
>> 
>> Without genhomedircon how do you expect to be able to label home
>> directories with the appropriate MLS levels for the LSPP version of
>> RH? 
>> 
> 
> Perhaps it would be better to set it explicitly rather than
> based on the user. Either by giving people a way to set MLS
> file contexts separately from the type (which might help with
> MLS customization in general) or just doing a chcon on the
> containing home directory and having that be inherited (and
> not set on relabel for home directories).
> 

So... Right now its based on the policy because the home directory
contexts are regenerated when the policy changes, you are suggesting
making it more difficult to use? Right now you can change someones level
with semanage and restorecon -R their home directory which is fairly
easy. Setting the contexts explicitly seems like much more burden on the
local admin.


--
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: [patch 0/4] libsemanage: genhomedircon replacement

[Stephen Smalley]

On Wed, 2007-08-15 at 11:57 -0400, Joshua Brindle wrote:
> Karl MacMillan wrote:
> > On Wed, 2007-08-15 at 11:29 -0400, Joshua Brindle wrote:
> >> Karl MacMillan wrote:
> >>> On Wed, 2007-08-15 at 16:44 -0400, tmiller@tresys.com wrote:
> >>>> This replaces genhomedircon with equivalent functionality in
> >>>> libsemanage. The homedir_template is also no longer installed, this
> >>>> leaves some unused path functions in libselinux but
> > removing those would break the ABI.
> >>>> 
> >>> 
> >>> On a higher level, perhaps we should stop doing per-role home
> >>> directory labeling at all and therefore remove genhomedircon
> >>> entirely. I've been thinking about how to work this on a LDAP based
> >>> network with remote home directories and I think the basic
> >>> conclusion is that role-based labeling will simply not work
> >>> (especially if we start assigning different primary roles to the
> >>> same user on different systems with the same remote home
> >>> directories). 
> >>> 
> >>> I suggest that we rely on either DAC or separate namespaces to
> >>> separate user access to home directories and have one set of types
> >>> for all home directories. On systems where you really want SELinux
> >>> to do the separation you can use user constraints (which could
> >>> either acheive the current role-level separation or user-level
> >>> separation based on how you map your SELinux users).
> >>> 
> >>> (BTW - most of the above was suggested to me by Dan and Steve in
> >>> private concersations). 
> >>> 
> >>> Thoughts?
> >> 
> >> Without genhomedircon how do you expect to be able to label home
> >> directories with the appropriate MLS levels for the LSPP version of
> >> RH? 
> >> 
> > 
> > Perhaps it would be better to set it explicitly rather than
> > based on the user. Either by giving people a way to set MLS
> > file contexts separately from the type (which might help with
> > MLS customization in general) or just doing a chcon on the
> > containing home directory and having that be inherited (and
> > not set on relabel for home directories).
> > 
> 
> So... Right now its based on the policy because the home directory
> contexts are regenerated when the policy changes, you are suggesting
> making it more difficult to use? Right now you can change someones level
> with semanage and restorecon -R their home directory which is fairly
> easy. Setting the contexts explicitly seems like much more burden on the
> local admin.

I thought genhomedircon wasn't setting the level at all (just using
whatever is in the template, i.e. s0), and then they were using
pam_namespace to instantiate per-level subdirs.

I'm trying to understand whether the issue here is limited in scope to
home directory labels or actually extends to the entire notion of
per-role types (tmp files, ttys, derived program domains, etc).  I know
that has long been an area of concern, not only for file relabeling but
also for e.g. modules (requires templating that would go beyond even
simple interfaces).

genhomedircon does serve another purpose, btw - setting the SELinux user
identity for the user's home directory.  So if you want to do separation
based on SELinux user via constraints, you still need a mechanism for
getting the user home directories to have the right SELinux user
identity.
  
-- 
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: [patch 0/4] libsemanage: genhomedircon replacement

[Joshua Brindle]

Stephen Smalley wrote:
> On Wed, 2007-08-15 at 11:57 -0400, Joshua Brindle wrote:
>> Karl MacMillan wrote:
>>> On Wed, 2007-08-15 at 11:29 -0400, Joshua Brindle wrote:
>>>> Karl MacMillan wrote:
>>>>> On Wed, 2007-08-15 at 16:44 -0400, tmiller@tresys.com wrote:
>>>>>> This replaces genhomedircon with equivalent functionality in
>>>>>> libsemanage. The homedir_template is also no longer installed,
>>>>>> this leaves some unused path functions in libselinux but
>>> removing those would break the ABI.
>>>>>> 
>>>>> 
>>>>> On a higher level, perhaps we should stop doing per-role home
>>>>> directory labeling at all and therefore remove genhomedircon
>>>>> entirely. I've been thinking about how to work this on a LDAP
>>>>> based network with remote home directories and I think the basic
>>>>> conclusion is that role-based labeling will simply not work
>>>>> (especially if we start assigning different primary roles to the
>>>>> same user on different systems with the same remote home
>>>>> directories). 
>>>>> 
>>>>> I suggest that we rely on either DAC or separate namespaces to
>>>>> separate user access to home directories and have one set of types
>>>>> for all home directories. On systems where you really want SELinux
>>>>> to do the separation you can use user constraints (which could
>>>>> either acheive the current role-level separation or user-level
>>>>> separation based on how you map your SELinux users).
>>>>> 
>>>>> (BTW - most of the above was suggested to me by Dan and Steve in
>>>>> private concersations). 
>>>>> 
>>>>> Thoughts?
>>>> 
>>>> Without genhomedircon how do you expect to be able to label home
>>>> directories with the appropriate MLS levels for the LSPP version
>>>> of RH? 
>>>> 
>>> 
>>> Perhaps it would be better to set it explicitly rather than based on
>>> the user. Either by giving people a way to set MLS file contexts
>>> separately from the type (which might help with MLS customization in
>>> general) or just doing a chcon on the containing home directory and
>>> having that be inherited (and not set on relabel for home
>>> directories). 
>>> 
>> 
>> So... Right now its based on the policy because the home directory
>> contexts are regenerated when the policy changes, you are suggesting
>> making it more difficult to use? Right now you can change someones
>> level with semanage and restorecon -R their home directory which is
>> fairly easy. Setting the contexts explicitly seems like much more
>> burden on the local admin.
> 
> I thought genhomedircon wasn't setting the level at all (just
> using whatever is in the template, i.e. s0), and then they
> were using pam_namespace to instantiate per-level subdirs.
> 

Oh right, I forgot pam_namespace was being used on all mls systems now.

> I'm trying to understand whether the issue here is limited in
> scope to home directory labels or actually extends to the
> entire notion of per-role types (tmp files, ttys, derived
> program domains, etc).  I know that has long been an area of
> concern, not only for file relabeling but also for e.g.
> modules (requires templating that would go beyond even simple
> interfaces). 
> 

I agree, however I don't want to rely on DAC for seperation of things
like tmp files. If it were easier to do automatic user/role transitions
on domains and files those might serve the purpose fine and still
provide good isolation via MAC but without that I'd hate to see per-role
types go away.

One example I already brought up offlist is webapps, particularly when
combined with something like se-postgresql there can be policy driven
seperation of data in one of the most exploited mediums around. It
doesn't matter if the seperation is via type: user_cgi_t can access
user_db_t or user: method:user_r:cgi_t can access method:object_r:db_t
or not, as long as there is some facility for getting a cgi of mine
running with the context method:user_r:cgi_t. 

> genhomedircon does serve another purpose, btw - setting the
> SELinux user identity for the user's home directory.  So if
> you want to do separation based on SELinux user via
> constraints, you still need a mechanism for getting the user
> home directories to have the right SELinux user identity.



--
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: [patch 0/4] libsemanage: genhomedircon replacement

[Karl MacMillan]

On Wed, 2007-08-15 at 13:37 -0400, Joshua Brindle wrote:
> Stephen Smalley wrote:
> > On Wed, 2007-08-15 at 11:57 -0400, Joshua Brindle wrote:

[...]

> > I'm trying to understand whether the issue here is limited in
> > scope to home directory labels or actually extends to the
> > entire notion of per-role types (tmp files, ttys, derived
> > program domains, etc).  I know that has long been an area of
> > concern, not only for file relabeling but also for e.g.
> > modules (requires templating that would go beyond even simple
> > interfaces). 
> > 
> 
> I agree, however I don't want to rely on DAC for seperation of things
> like tmp files.

But the current role-based separation is not what we want either - for
tmp we really want this to be per-user. For the tmp types we could use
constraints on users (this is easier than the constraints for home
directories because the tmp files will always be created by a user
process and therefore have the correct user labeling without a
genhomedircon like tool).

But again, namespace based separation may be the easiest solution here.
Or type + dac might be sufficient.

>  If it were easier to do automatic user/role transitions
> on domains and files those might serve the purpose fine and still
> provide good isolation via MAC but without that I'd hate to see per-role
> types go away.
> 

I agree that user transitions would be helpful.

> One example I already brought up offlist is webapps, particularly when
> combined with something like se-postgresql there can be policy driven
> seperation of data in one of the most exploited mediums around. It
> doesn't matter if the seperation is via type: user_cgi_t can access
> user_db_t or user: method:user_r:cgi_t can access method:object_r:db_t
> or not, as long as there is some facility for getting a cgi of mine
> running with the context method:user_r:cgi_t. 
> 

Right - and part of my argument here is that if it is really user based
separation then let's do user based separation and not this halfway
role-based / type separation. It's causing more problems than its
solving.

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: [patch 0/4] libsemanage: genhomedircon replacement

[Karl MacMillan]

On Wed, 2007-08-15 at 13:22 -0400, Stephen Smalley wrote:
> On Wed, 2007-08-15 at 11:57 -0400, Joshua Brindle wrote:
> > Karl MacMillan wrote:
[...]
> > > Perhaps it would be better to set it explicitly rather than
> > > based on the user. Either by giving people a way to set MLS
> > > file contexts separately from the type (which might help with
> > > MLS customization in general) or just doing a chcon on the
> > > containing home directory and having that be inherited (and
> > > not set on relabel for home directories).
> > > 
> > 
> > So... Right now its based on the policy because the home directory
> > contexts are regenerated when the policy changes, you are suggesting
> > making it more difficult to use? Right now you can change someones level
> > with semanage and restorecon -R their home directory which is fairly
> > easy. Setting the contexts explicitly seems like much more burden on the
> > local admin.
> 
> I thought genhomedircon wasn't setting the level at all (just using
> whatever is in the template, i.e. s0), and then they were using
> pam_namespace to instantiate per-level subdirs.
> 

Which sounds better (and safer - relabeling the level would be
questionable). However, having a mechanism to set levels separate from
type (and potentially user) sounds helpful. That way an admin could
specify, for example, that a log file should be Secret without having to
specify the type.

> I'm trying to understand whether the issue here is limited in scope to
> home directory labels or actually extends to the entire notion of
> per-role types (tmp files, ttys, derived program domains, etc).  I know
> that has long been an area of concern, not only for file relabeling but
> also for e.g. modules (requires templating that would go beyond even
> simple interfaces).
> 

I wonder too. I think that we need a means to create limited-privilege
login sessions and control movement between privileged domains (and
related domains through transitions). This can be done with much of the
current role infrastructure (see Dan's work on guest_t and xguest_t). We
can keep the process domains without instantiating corresponding file
types.

However, the problem with the current per-role templates is that they
are instantiated for _every_ role, which is clearly wrong for certain
types of locked-down roles. If I want a git-role that only allows a user
to login to a bash shell, execute git, and read / write certain file
types having a git_firefox_t is not desirable.

> genhomedircon does serve another purpose, btw - setting the SELinux user
> identity for the user's home directory.  So if you want to do separation
> based on SELinux user via constraints, you still need a mechanism for
> getting the user home directories to have the right SELinux user
> identity.
>   

I have two suggestions (which may be totally off-base):

1) Remove the selinux user concept entirely and merge it with the DAC
user identities. We would simply preserve the role authorizations and
allow constraints on the dac users (there are some interesting details
in there I know). The constraints could be limited to user equality /
inequality and not refer to specific users to simplify things.

2) The above separated file contexts that allow mapping of only the user
portion to a regex. This would allow us to have admin specified mappings
of users, but default to the same user. I'm hesitant about this one -
remember part of the problem is that we don't want to enumerate every
user in an LDAP database to do file system labeling.

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: [patch 0/4] libsemanage: genhomedircon replacement

[Stephen Smalley]

On Wed, 2007-08-15 at 15:16 -0400, Karl MacMillan wrote:
> On Wed, 2007-08-15 at 13:22 -0400, Stephen Smalley wrote:
> > On Wed, 2007-08-15 at 11:57 -0400, Joshua Brindle wrote:
> > > Karl MacMillan wrote:
> [...]
> > > > Perhaps it would be better to set it explicitly rather than
> > > > based on the user. Either by giving people a way to set MLS
> > > > file contexts separately from the type (which might help with
> > > > MLS customization in general) or just doing a chcon on the
> > > > containing home directory and having that be inherited (and
> > > > not set on relabel for home directories).
> > > > 
> > > 
> > > So... Right now its based on the policy because the home directory
> > > contexts are regenerated when the policy changes, you are suggesting
> > > making it more difficult to use? Right now you can change someones level
> > > with semanage and restorecon -R their home directory which is fairly
> > > easy. Setting the contexts explicitly seems like much more burden on the
> > > local admin.
> > 
> > I thought genhomedircon wasn't setting the level at all (just using
> > whatever is in the template, i.e. s0), and then they were using
> > pam_namespace to instantiate per-level subdirs.
> > 
> 
> Which sounds better (and safer - relabeling the level would be
> questionable). However, having a mechanism to set levels separate from
> type (and potentially user) sounds helpful. That way an admin could
> specify, for example, that a log file should be Secret without having to
> specify the type.
> 
> > I'm trying to understand whether the issue here is limited in scope to
> > home directory labels or actually extends to the entire notion of
> > per-role types (tmp files, ttys, derived program domains, etc).  I know
> > that has long been an area of concern, not only for file relabeling but
> > also for e.g. modules (requires templating that would go beyond even
> > simple interfaces).
> > 
> 
> I wonder too. I think that we need a means to create limited-privilege
> login sessions and control movement between privileged domains (and
> related domains through transitions). This can be done with much of the
> current role infrastructure (see Dan's work on guest_t and xguest_t). We
> can keep the process domains without instantiating corresponding file
> types.
> 
> However, the problem with the current per-role templates is that they
> are instantiated for _every_ role, which is clearly wrong for certain
> types of locked-down roles. If I want a git-role that only allows a user
> to login to a bash shell, execute git, and read / write certain file
> types having a git_firefox_t is not desirable.
> 
> > genhomedircon does serve another purpose, btw - setting the SELinux user
> > identity for the user's home directory.  So if you want to do separation
> > based on SELinux user via constraints, you still need a mechanism for
> > getting the user home directories to have the right SELinux user
> > identity.
> >   
> 
> I have two suggestions (which may be totally off-base):
> 
> 1) Remove the selinux user concept entirely and merge it with the DAC
> user identities. We would simply preserve the role authorizations and
> allow constraints on the dac users (there are some interesting details
> in there I know). The constraints could be limited to user equality /
> inequality and not refer to specific users to simplify things.

By remove/merge, do you mean just use the Linux username as the SELinux
user identity, like we used to do before seusers?  You can even do that
today just by removing seusers or making it empty.  The problem with
that approach I thought was that it required regenerating and loading
kernel policy each time we add or remove a Linux user.

What permissions do you intend to constrain?  If all read/write, then
there would need to be e.g. an exception for any sharing of data between
users and any access to the base system.  Default constraints under
strict policy only constrained ability to create or relabel objects with
different user identity.

> 2) The above separated file contexts that allow mapping of only the user
> portion to a regex. This would allow us to have admin specified mappings
> of users, but default to the same user. I'm hesitant about this one -
> remember part of the problem is that we don't want to enumerate every
> user in an LDAP database to do file system labeling.

I'm not sure why you'd have such a mapping at all; it is implicit
(passwd database already maps Linux username to home directory location,
and if we are using Linux username as SELinux user identity, then the
tool knows what SELinux user to apply to all files in that home
directory).

-- 
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: [patch 0/4] libsemanage: genhomedircon replacement

[Karl MacMillan]

On Wed, 2007-08-15 at 15:56 -0400, Stephen Smalley wrote:
> On Wed, 2007-08-15 at 15:16 -0400, Karl MacMillan wrote:
> > On Wed, 2007-08-15 at 13:22 -0400, Stephen Smalley wrote:
> > > On Wed, 2007-08-15 at 11:57 -0400, Joshua Brindle wrote:
> > > > Karl MacMillan wrote:
> > [...]
> > > > > Perhaps it would be better to set it explicitly rather than
> > > > > based on the user. Either by giving people a way to set MLS
> > > > > file contexts separately from the type (which might help with
> > > > > MLS customization in general) or just doing a chcon on the
> > > > > containing home directory and having that be inherited (and
> > > > > not set on relabel for home directories).
> > > > > 
> > > > 
> > > > So... Right now its based on the policy because the home directory
> > > > contexts are regenerated when the policy changes, you are suggesting
> > > > making it more difficult to use? Right now you can change someones level
> > > > with semanage and restorecon -R their home directory which is fairly
> > > > easy. Setting the contexts explicitly seems like much more burden on the
> > > > local admin.
> > > 
> > > I thought genhomedircon wasn't setting the level at all (just using
> > > whatever is in the template, i.e. s0), and then they were using
> > > pam_namespace to instantiate per-level subdirs.
> > > 
> > 
> > Which sounds better (and safer - relabeling the level would be
> > questionable). However, having a mechanism to set levels separate from
> > type (and potentially user) sounds helpful. That way an admin could
> > specify, for example, that a log file should be Secret without having to
> > specify the type.
> > 
> > > I'm trying to understand whether the issue here is limited in scope to
> > > home directory labels or actually extends to the entire notion of
> > > per-role types (tmp files, ttys, derived program domains, etc).  I know
> > > that has long been an area of concern, not only for file relabeling but
> > > also for e.g. modules (requires templating that would go beyond even
> > > simple interfaces).
> > > 
> > 
> > I wonder too. I think that we need a means to create limited-privilege
> > login sessions and control movement between privileged domains (and
> > related domains through transitions). This can be done with much of the
> > current role infrastructure (see Dan's work on guest_t and xguest_t). We
> > can keep the process domains without instantiating corresponding file
> > types.
> > 
> > However, the problem with the current per-role templates is that they
> > are instantiated for _every_ role, which is clearly wrong for certain
> > types of locked-down roles. If I want a git-role that only allows a user
> > to login to a bash shell, execute git, and read / write certain file
> > types having a git_firefox_t is not desirable.
> > 
> > > genhomedircon does serve another purpose, btw - setting the SELinux user
> > > identity for the user's home directory.  So if you want to do separation
> > > based on SELinux user via constraints, you still need a mechanism for
> > > getting the user home directories to have the right SELinux user
> > > identity.
> > >   
> > 
> > I have two suggestions (which may be totally off-base):
> > 
> > 1) Remove the selinux user concept entirely and merge it with the DAC
> > user identities. We would simply preserve the role authorizations and
> > allow constraints on the dac users (there are some interesting details
> > in there I know). The constraints could be limited to user equality /
> > inequality and not refer to specific users to simplify things.
> 
> By remove/merge, do you mean just use the Linux username as the SELinux
> user identity, like we used to do before seusers?  You can even do that
> today just by removing seusers or making it empty.  The problem with
> that approach I thought was that it required regenerating and loading
> kernel policy each time we add or remove a Linux user.
> 

No, I mean removing the separate user identity entirely and allowing
selinux to directly use the linux user identity where appropriate (e.g.,
for constraints). This may be an awful idea, it's just that we abandoned
SELinux knowledge of individual users because of scalability problems
(which seems somewhat unfortunate) and added a somewhat redundant level
of indirection. Allowing direct interaction with the linux user identity
would solve the scalability while giving selinux a chance to have policy
around individual users.

> What permissions do you intend to constrain?  If all read/write, then
> there would need to be e.g. an exception for any sharing of data between
> users and any access to the base system.  Default constraints under
> strict policy only constrained ability to create or relabel objects with
> different user identity.
> 

For the home directories? Nothing additional by default - just let DAC
do the separation. For certain types (like ssh types or the bashrc),
perhaps complete separation for users unless the program has an
override. Same for tmp types. (this is just a suggestion - nothing
concrete).

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: [patch 0/4] libsemanage: genhomedircon replacement

[Stephen Smalley]

On Wed, 2007-08-15 at 16:17 -0400, Karl MacMillan wrote:
> On Wed, 2007-08-15 at 15:56 -0400, Stephen Smalley wrote:
> > On Wed, 2007-08-15 at 15:16 -0400, Karl MacMillan wrote:
> > > On Wed, 2007-08-15 at 13:22 -0400, Stephen Smalley wrote:
> > > > On Wed, 2007-08-15 at 11:57 -0400, Joshua Brindle wrote:
> > > > > Karl MacMillan wrote:
> > > [...]
> > > > > > Perhaps it would be better to set it explicitly rather than
> > > > > > based on the user. Either by giving people a way to set MLS
> > > > > > file contexts separately from the type (which might help with
> > > > > > MLS customization in general) or just doing a chcon on the
> > > > > > containing home directory and having that be inherited (and
> > > > > > not set on relabel for home directories).
> > > > > > 
> > > > > 
> > > > > So... Right now its based on the policy because the home directory
> > > > > contexts are regenerated when the policy changes, you are suggesting
> > > > > making it more difficult to use? Right now you can change someones level
> > > > > with semanage and restorecon -R their home directory which is fairly
> > > > > easy. Setting the contexts explicitly seems like much more burden on the
> > > > > local admin.
> > > > 
> > > > I thought genhomedircon wasn't setting the level at all (just using
> > > > whatever is in the template, i.e. s0), and then they were using
> > > > pam_namespace to instantiate per-level subdirs.
> > > > 
> > > 
> > > Which sounds better (and safer - relabeling the level would be
> > > questionable). However, having a mechanism to set levels separate from
> > > type (and potentially user) sounds helpful. That way an admin could
> > > specify, for example, that a log file should be Secret without having to
> > > specify the type.
> > > 
> > > > I'm trying to understand whether the issue here is limited in scope to
> > > > home directory labels or actually extends to the entire notion of
> > > > per-role types (tmp files, ttys, derived program domains, etc).  I know
> > > > that has long been an area of concern, not only for file relabeling but
> > > > also for e.g. modules (requires templating that would go beyond even
> > > > simple interfaces).
> > > > 
> > > 
> > > I wonder too. I think that we need a means to create limited-privilege
> > > login sessions and control movement between privileged domains (and
> > > related domains through transitions). This can be done with much of the
> > > current role infrastructure (see Dan's work on guest_t and xguest_t). We
> > > can keep the process domains without instantiating corresponding file
> > > types.
> > > 
> > > However, the problem with the current per-role templates is that they
> > > are instantiated for _every_ role, which is clearly wrong for certain
> > > types of locked-down roles. If I want a git-role that only allows a user
> > > to login to a bash shell, execute git, and read / write certain file
> > > types having a git_firefox_t is not desirable.
> > > 
> > > > genhomedircon does serve another purpose, btw - setting the SELinux user
> > > > identity for the user's home directory.  So if you want to do separation
> > > > based on SELinux user via constraints, you still need a mechanism for
> > > > getting the user home directories to have the right SELinux user
> > > > identity.
> > > >   
> > > 
> > > I have two suggestions (which may be totally off-base):
> > > 
> > > 1) Remove the selinux user concept entirely and merge it with the DAC
> > > user identities. We would simply preserve the role authorizations and
> > > allow constraints on the dac users (there are some interesting details
> > > in there I know). The constraints could be limited to user equality /
> > > inequality and not refer to specific users to simplify things.
> > 
> > By remove/merge, do you mean just use the Linux username as the SELinux
> > user identity, like we used to do before seusers?  You can even do that
> > today just by removing seusers or making it empty.  The problem with
> > that approach I thought was that it required regenerating and loading
> > kernel policy each time we add or remove a Linux user.
> > 
> 
> No, I mean removing the separate user identity entirely and allowing
> selinux to directly use the linux user identity where appropriate (e.g.,
> for constraints). This may be an awful idea, it's just that we abandoned

s/may be/is/

> SELinux knowledge of individual users because of scalability problems
> (which seems somewhat unfortunate) and added a somewhat redundant level
> of indirection. Allowing direct interaction with the linux user identity
> would solve the scalability while giving selinux a chance to have policy
> around individual users.

It isn't quite redundant.  Today the SELinux user is an "authorized role
set", while the role field indicates the active role.  So it still
functions as a bound on what roles are reachable by the user, and means
that newrole isn't completely trusted (can't jump to an arbitrary role,
but only to one in the "authorized role set" identified by the SELinux
user).

If we gave that up, then newrole would be a completely trusted program,
i.e. it would fully adjudicate what roles can be entered by what users.

The Linux uid is less useful to us, as we certainly don't want to encode
uids (integers) into the SELinux policy, so defining user-role
authorizations based on Linux uid in kernel policy isn't going to be
workable.

Also, the fact that the Linux uid can be changed by a suid application
makes it a less reliable source of information.

Simple uid comparisons are what we essentially get from DAC.

So if you wanted to toss user-role authorizations by the kernel to the
winds, you can achieve that by defining a single SELinux user
(authorized for all roles in kernel policy), handling the Linux user ->
role mapping entirely in seusers, and adjudicating that in login, sshd,
and newrole.

> > What permissions do you intend to constrain?  If all read/write, then
> > there would need to be e.g. an exception for any sharing of data between
> > users and any access to the base system.  Default constraints under
> > strict policy only constrained ability to create or relabel objects with
> > different user identity.
> > 
> 
> For the home directories? Nothing additional by default - just let DAC
> do the separation. For certain types (like ssh types or the bashrc),
> perhaps complete separation for users unless the program has an
> override. Same for tmp types. (this is just a suggestion - nothing
> concrete).

-- 
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: [patch 0/4] libsemanage: genhomedircon replacement

[Karl MacMillan]

On Wed, 2007-08-15 at 16:31 -0400, Stephen Smalley wrote:
> On Wed, 2007-08-15 at 16:17 -0400, Karl MacMillan wrote:
> > On Wed, 2007-08-15 at 15:56 -0400, Stephen Smalley wrote:

[...]

> > > By remove/merge, do you mean just use the Linux username as the SELinux
> > > user identity, like we used to do before seusers?  You can even do that
> > > today just by removing seusers or making it empty.  The problem with
> > > that approach I thought was that it required regenerating and loading
> > > kernel policy each time we add or remove a Linux user.
> > > 
> > 
> > No, I mean removing the separate user identity entirely and allowing
> > selinux to directly use the linux user identity where appropriate (e.g.,
> > for constraints). This may be an awful idea, it's just that we abandoned
> 
> s/may be/is/
> 

Glad we cleared that up :)

> > SELinux knowledge of individual users because of scalability problems
> > (which seems somewhat unfortunate) and added a somewhat redundant level
> > of indirection. Allowing direct interaction with the linux user identity
> > would solve the scalability while giving selinux a chance to have policy
> > around individual users.
> 
> It isn't quite redundant.  Today the SELinux user is an "authorized role
> set", while the role field indicates the active role.  So it still
> functions as a bound on what roles are reachable by the user, and means
> that newrole isn't completely trusted (can't jump to an arbitrary role,
> but only to one in the "authorized role set" identified by the SELinux
> user).
> 
> If we gave that up, then newrole would be a completely trusted program,
> i.e. it would fully adjudicate what roles can be entered by what users.
> 
> The Linux uid is less useful to us, as we certainly don't want to encode
> uids (integers) into the SELinux policy, so defining user-role
> authorizations based on Linux uid in kernel policy isn't going to be
> workable.
> 
> Also, the fact that the Linux uid can be changed by a suid application
> makes it a less reliable source of information.
> 
> Simple uid comparisons are what we essentially get from DAC.
> 
> So if you wanted to toss user-role authorizations by the kernel to the
> winds, you can achieve that by defining a single SELinux user
> (authorized for all roles in kernel policy), handling the Linux user ->
> role mapping entirely in seusers, and adjudicating that in login, sshd,
> and newrole.
> 

Ok - I'm convinced (teach me to brain storm over email). So I'm fine
with leaving user-level separation to DAC / namespace and leave the
current selinux users.

So I vote for removing genhomedircon entirely unless some other
objection comes up. Anyone that wants that behavior could certainly set
something up fairly easily.

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: [patch 0/4] libsemanage: genhomedircon replacement

[Joshua Brindle]

Karl MacMillan wrote:
> On Wed, 2007-08-15 at 16:31 -0400, Stephen Smalley wrote:
> 
> So I vote for removing genhomedircon entirely unless some
> other objection comes up. Anyone that wants that behavior
> could certainly set something up fairly easily.
> 

You haven't addressed the other concerns (policy server, user labeling
of home directories, etc). It needs to stay and people that don't want
it don't have to use it. 



--
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: [patch 0/4] libsemanage: genhomedircon replacement

[Karl MacMillan]

On Wed, 2007-08-15 at 16:47 -0400, Joshua Brindle wrote:
> Karl MacMillan wrote:
> > On Wed, 2007-08-15 at 16:31 -0400, Stephen Smalley wrote:
> > 
> > So I vote for removing genhomedircon entirely unless some
> > other objection comes up. Anyone that wants that behavior
> > could certainly set something up fairly easily.
> > 
> 
> You haven't addressed the other concerns (policy server

Until this is available upstream or it is certain that it will be merged
I don't think we can make decisions around the policy server. It is
simply too much of an unknown.

Your question didn't make it to this list - here it is for others:

"They are needed for policy server to allow users to make changes to
their policy. We need something like

Type httpd_ROLE_script_ra       system_u:object_r:httpd_ROLE_types_t
Type httpd_ROLE_script_ro       system_u:object_r:httpd_ROLE_types_t

So that users can be granted access to use those types in modules:

Allow user_t httpd_user_types_t: type { add use };

And can create new types in their type space for finer grained access
control."

Role expansion can happen during the policy build - it doesn't depend on
system information (especially since role expansion doesn't work for
modules).

>   user labeling
> of home directories, etc).

The current method simply does not scale - it can't possibly work on
systems with users in LDAP (enumeration of all users is just too
expensive). So genhomedircon is not an answer to this.

The options that we have are:

1) Have restorecon set this at runtime for home directories (it has all
of the needed informaiton - there is no reason to do an expansion like
genhomedircon does).

2) Abandon automatic user re-labeling for home directories by default.
The initial label could be set and inherited on the home directory at
creation (or done explicitly by the admin) and restorecon will just not
reset the user part of the context (I believe this is the current
default).

>  It needs to stay and people that don't want
> it don't have to use it. 
> 

a) there is no real way to not use it currently and
b) every time there is a choice like this it has a huge impact on
maintenance and usability.

I think we should make a choice and support one standard way of doing
things. People are still free to customize, but the upstream should have
one standard.

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: [patch 0/4] libsemanage: genhomedircon replacement

[Joshua Brindle]

Karl MacMillan wrote:
> On Wed, 2007-08-15 at 16:47 -0400, Joshua Brindle wrote:
>> Karl MacMillan wrote:
>>> On Wed, 2007-08-15 at 16:31 -0400, Stephen Smalley wrote:
>>> 
>>> So I vote for removing genhomedircon entirely unless some other
>>> objection comes up. Anyone that wants that behavior could certainly
>>> set something up fairly easily.
>>> 
>> 
>> You haven't addressed the other concerns (policy server
> 
> Until this is available upstream or it is certain that it
> will be merged I don't think we can make decisions around the
> policy server. It is simply too much of an unknown.
> 
> Your question didn't make it to this list - here it is for others:
> 
> "They are needed for policy server to allow users to make
> changes to their policy. We need something like
> 
> Type httpd_ROLE_script_ra       system_u:object_r:httpd_ROLE_types_t
> Type httpd_ROLE_script_ro       system_u:object_r:httpd_ROLE_types_t
> 
> So that users can be granted access to use those types in modules:
> 
> Allow user_t httpd_user_types_t: type { add use };
> 
> And can create new types in their type space for finer
> grained access control."
> 
> Role expansion can happen during the policy build - it
> doesn't depend on system information (especially since role
> expansion doesn't work for modules).
> 
>>   user labeling
>> of home directories, etc).
> 
> The current method simply does not scale - it can't possibly
> work on systems with users in LDAP (enumeration of all users
> is just too expensive). So genhomedircon is not an answer to this.
> 
> The options that we have are:
> 
> 1) Have restorecon set this at runtime for home directories
> (it has all of the needed informaiton - there is no reason to
> do an expansion like genhomedircon does).
> 
> 2) Abandon automatic user re-labeling for home directories by default.
> The initial label could be set and inherited on the home
> directory at creation (or done explicitly by the admin) and
> restorecon will just not reset the user part of the context
> (I believe this is the current default).
> 
>>  It needs to stay and people that don't want it don't have to use it.
>> 
> 
> a) there is no real way to not use it currently and
> b) every time there is a choice like this it has a huge
> impact on maintenance and usability.
> 
> I think we should make a choice and support one standard way
> of doing things. People are still free to customize, but the
> upstream should have one standard.
> 

Then the upstream should have it available. RH doesn't have to use it
but like I told you off list we have systems that use it and need it. 


--
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: [patch 0/4] libsemanage: genhomedircon replacement

[Joshua Brindle]

Joshua Brindle wrote:
> Karl MacMillan wrote:
>> On Wed, 2007-08-15 at 16:47 -0400, Joshua Brindle wrote:
>>> Karl MacMillan wrote:
>>>> On Wed, 2007-08-15 at 16:31 -0400, Stephen Smalley wrote:
>>>>
>>>> So I vote for removing genhomedircon entirely unless some other
>>>> objection comes up. Anyone that wants that behavior could certainly
>>>> set something up fairly easily.
>>>>
>>> You haven't addressed the other concerns (policy server
>> Until this is available upstream or it is certain that it
>> will be merged I don't think we can make decisions around the
>> policy server. It is simply too much of an unknown.
>>
>> Your question didn't make it to this list - here it is for others:
>>
>> "They are needed for policy server to allow users to make
>> changes to their policy. We need something like
>>
>> Type httpd_ROLE_script_ra       system_u:object_r:httpd_ROLE_types_t
>> Type httpd_ROLE_script_ro       system_u:object_r:httpd_ROLE_types_t
>>
>> So that users can be granted access to use those types in modules:
>>
>> Allow user_t httpd_user_types_t: type { add use };
>>
>> And can create new types in their type space for finer
>> grained access control."
>>
>> Role expansion can happen during the policy build - it
>> doesn't depend on system information (especially since role
>> expansion doesn't work for modules).
>>
>>>   user labeling
>>> of home directories, etc).
>> The current method simply does not scale - it can't possibly
>> work on systems with users in LDAP (enumeration of all users
>> is just too expensive). So genhomedircon is not an answer to this.
>>
>> The options that we have are:
>>
>> 1) Have restorecon set this at runtime for home directories
>> (it has all of the needed informaiton - there is no reason to
>> do an expansion like genhomedircon does).
>>
>> 2) Abandon automatic user re-labeling for home directories by default.
>> The initial label could be set and inherited on the home
>> directory at creation (or done explicitly by the admin) and
>> restorecon will just not reset the user part of the context
>> (I believe this is the current default).
>>
>>>  It needs to stay and people that don't want it don't have to use it.
>>>
>> a) there is no real way to not use it currently and
>> b) every time there is a choice like this it has a huge
>> impact on maintenance and usability.
>>
>> I think we should make a choice and support one standard way
>> of doing things. People are still free to customize, but the
>> upstream should have one standard.
>>
> 
> Then the upstream should have it available. RH doesn't have to use it
> but like I told you off list we have systems that use it and need it. 
> 

Targeted policy doesn't need it at all and it just slows down otherwise 
faster operations. We can add a flag to disable it in this patchset if 
that is desired.



--
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: [patch 0/4] libsemanage: genhomedircon replacement

[Karl MacMillan]

On Wed, 2007-08-15 at 17:12 -0400, Joshua Brindle wrote:
> Karl MacMillan wrote:
> > On Wed, 2007-08-15 at 16:47 -0400, Joshua Brindle wrote:

[...]

> > 
> > a) there is no real way to not use it currently and
> > b) every time there is a choice like this it has a huge
> > impact on maintenance and usability.
> > 
> > I think we should make a choice and support one standard way
> > of doing things. People are still free to customize, but the
> > upstream should have one standard.
> > 
> 
> Then the upstream should have it available. RH doesn't have to use it
> but like I told you off list we have systems that use it and need it. 

I'd really like to here _why_ they need per-role home directory types -
so far you haven't explained that. I think this is an important problem
to fix because I don't see how current practice can possibly work with
users stored in a directory or remote home directories.

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: [patch 0/4] libsemanage: genhomedircon replacement

[Stephen Smalley]

On Wed, 2007-08-15 at 17:09 -0400, Karl MacMillan wrote:
> On Wed, 2007-08-15 at 16:47 -0400, Joshua Brindle wrote:
> > Karl MacMillan wrote:
> > > On Wed, 2007-08-15 at 16:31 -0400, Stephen Smalley wrote:
> > > 
> > > So I vote for removing genhomedircon entirely unless some
> > > other objection comes up. Anyone that wants that behavior
> > > could certainly set something up fairly easily.
> > > 
> > 
> > You haven't addressed the other concerns (policy server
> 
> Until this is available upstream or it is certain that it will be merged
> I don't think we can make decisions around the policy server. It is
> simply too much of an unknown.
> 
> Your question didn't make it to this list - here it is for others:
> 
> "They are needed for policy server to allow users to make changes to
> their policy. We need something like
> 
> Type httpd_ROLE_script_ra       system_u:object_r:httpd_ROLE_types_t
> Type httpd_ROLE_script_ro       system_u:object_r:httpd_ROLE_types_t
> 
> So that users can be granted access to use those types in modules:
> 
> Allow user_t httpd_user_types_t: type { add use };
> 
> And can create new types in their type space for finer grained access
> control."
> 
> Role expansion can happen during the policy build - it doesn't depend on
> system information (especially since role expansion doesn't work for
> modules).
> 
> >   user labeling
> > of home directories, etc).
> 
> The current method simply does not scale - it can't possibly work on
> systems with users in LDAP (enumeration of all users is just too
> expensive). So genhomedircon is not an answer to this.
> 
> The options that we have are:
> 
> 1) Have restorecon set this at runtime for home directories (it has all
> of the needed informaiton - there is no reason to do an expansion like
> genhomedircon does).
> 
> 2) Abandon automatic user re-labeling for home directories by default.
> The initial label could be set and inherited on the home directory at
> creation (or done explicitly by the admin) and restorecon will just not
> reset the user part of the context (I believe this is the current
> default).
> 
> >  It needs to stay and people that don't want
> > it don't have to use it. 
> > 
> 
> a) there is no real way to not use it currently and
> b) every time there is a choice like this it has a huge impact on
> maintenance and usability.
> 
> I think we should make a choice and support one standard way of doing
> things. People are still free to customize, but the upstream should have
> one standard.

I guess I'm confused.  genhomedircon has been present in upstream
selinux for some time, so we can't just remove it without providing
equivalent functionality.

Not generating per-role types can be done by shipping a homedir_template
with no "macros" (ROLE).

It doesn't actually walk all users, does it?  Just ones that have
explicit entries in seusers (everyone else falling back to the default
and having their home directories labeled with the base set of home
directory types for user_t).

So what's the real problem with leaving it intact, and just changing
your usage if you don't want per-role home directory types.

-- 
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: [patch 0/4] libsemanage: genhomedircon replacement

[Karl MacMillan]

On Thu, 2007-08-16 at 12:01 -0400, Stephen Smalley wrote:
> On Wed, 2007-08-15 at 17:09 -0400, Karl MacMillan wrote:
> > On Wed, 2007-08-15 at 16:47 -0400, Joshua Brindle wrote:

[...]

> 
> I guess I'm confused.  genhomedircon has been present in upstream
> selinux for some time, so we can't just remove it without providing
> equivalent functionality.
> 

Well - it would have to be coordinated with policy updates. I guess I'd
be fine with providing a way to optionally run it.

> Not generating per-role types can be done by shipping a homedir_template
> with no "macros" (ROLE).
> 
> It doesn't actually walk all users, does it? 

Not the current version.

>  Just ones that have
> explicit entries in seusers (everyone else falling back to the default
> and having their home directories labeled with the base set of home
> directory types for user_t).
> 

I'm still concerned about the number of calls out to a directory for a
large seusers file and eventually I want to push the seusers mapping
into the directory as well.

I'm also thinking about when we finally have labeled, remote home
directories. Each system trying to label home directories based on its
view of the default role for a user is going to break horribly.

> So what's the real problem with leaving it intact, and just changing
> your usage if you don't want per-role home directory types.
> 

If it can be completely disabled that's fine (this is assuming that Dan
wants to make this change on home directory labeling). What I'm really
pushing for is reconsidering whether the current practice makes sense
and considering the problems that it causes. I'm probably go about this
the wrong way as there hasn't been much discussion on that point.

As I'm trying to make user home directories work in a typical remote
homedir / directory setting I would like to get the defaults changed
sooner so that when that support finally shows up we are ready.

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: [patch 0/4] libsemanage: genhomedircon replacement

[Joshua Brindle]

Karl MacMillan wrote:
> On Thu, 2007-08-16 at 12:01 -0400, Stephen Smalley wrote:
>> On Wed, 2007-08-15 at 17:09 -0400, Karl MacMillan wrote:
>>> On Wed, 2007-08-15 at 16:47 -0400, Joshua Brindle wrote:
> 
> [...]
> 
>> I guess I'm confused.  genhomedircon has been present in upstream
>> selinux for some time, so we can't just remove it without providing
>> equivalent functionality.
>>
> 
> Well - it would have to be coordinated with policy updates. I guess I'd
> be fine with providing a way to optionally run it.
> 
>> Not generating per-role types can be done by shipping a homedir_template
>> with no "macros" (ROLE).
>>
>> It doesn't actually walk all users, does it? 
> 
> Not the current version.
> 
>>  Just ones that have
>> explicit entries in seusers (everyone else falling back to the default
>> and having their home directories labeled with the base set of home
>> directory types for user_t).
>>
> 
> I'm still concerned about the number of calls out to a directory for a
> large seusers file and eventually I want to push the seusers mapping
> into the directory as well.
>

So, the number of calls to the directory server directly corresponds to 
how crappy the code calling out to said directory server is. That is, 
LDAP does allow one to query the server and get lots of entries out at 
once. I suspect this is a problem with using pam, is that right?


> I'm also thinking about when we finally have labeled, remote home
> directories. Each system trying to label home directories based on its
> view of the default role for a user is going to break horribly.
> 

sounds like you are going to have some sort of cooperation with the 
policy anyway, why not extend that to labeling?

>> So what's the real problem with leaving it intact, and just changing
>> your usage if you don't want per-role home directory types.
>>
> 
> If it can be completely disabled that's fine (this is assuming that Dan
> wants to make this change on home directory labeling). What I'm really
> pushing for is reconsidering whether the current practice makes sense
> and considering the problems that it causes. I'm probably go about this
> the wrong way as there hasn't been much discussion on that point.
> 
> As I'm trying to make user home directories work in a typical remote
> homedir / directory setting I would like to get the defaults changed
> sooner so that when that support finally shows up we are ready.
> 

Weren't you just griping at me for trying to support stuff that isn't 
"upstream" yet...


--
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: [patch 0/4] libsemanage: genhomedircon replacement

[Daniel J Walsh]

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

Finally catching up on Email after vacation.

genhomedircon lists the entire list of passwords in order to figure out
where home directories are.  Not just the contents of the seusers.

At RedHat we have about 50 different root home directories

/home/location/dwalsh

We need to know this in order to have restorecon work properly.

Labeling of the homedir for things like .mozilla .gnome2 and .ssh
is still needed, but differentiating them on Roles does not make sense
in a distributed world.  Where if dwalsh logs into a kiosk machine he
might be xguest_t, on a terminal server guest_t, on his local machine
unconfined_t and on the security machine staff_t.  If his home directory
is the same on all of these, SELinux is in trouble.

I would be fine with the /tmp differentiation based on role, although I
believe that most machines will have almost everyone using the same role
so you have little separation.  Now that XWindows no longer requires
/tmp.  pam_namespace is a much better solution for this.

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

iD8DBQFG0w7mrlYvE4MpobMRArZ5AJ9epyM+nDcr5ONXr3ZQVOCOyLDUtwCg2hjJ
NVP3ISNd7Fd0jrq4tFh2/eE=
=l+ea
-----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: [patch 0/4] libsemanage: genhomedircon replacement

[Joshua Brindle]

Daniel J Walsh wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Finally catching up on Email after vacation.
> 
> genhomedircon lists the entire list of passwords in order to figure out
> where home directories are.  Not just the contents of the seusers.
> 

Is there an implementation error in the new genhomedircon?

> At RedHat we have about 50 different root home directories
> 
> /home/location/dwalsh
> 
> We need to know this in order to have restorecon work properly.
> 
> Labeling of the homedir for things like .mozilla .gnome2 and .ssh
> is still needed, but differentiating them on Roles does not make sense
> in a distributed world.  Where if dwalsh logs into a kiosk machine he
> might be xguest_t, on a terminal server guest_t, on his local machine
> unconfined_t and on the security machine staff_t.  If his home directory
> is the same on all of these, SELinux is in trouble.

So, it doesn't make sense for your specific infrastructure, that doesn't 
mean it doesn't make sense ever. And this is a policy issue really, 
genhomedircon just does what its told.


--
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: [patch 0/4] libsemanage: genhomedircon replacement

[Stephen Smalley]

On Tue, 2007-08-28 at 10:21 -0400, Joshua Brindle wrote:
> Daniel J Walsh wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> > 
> > Finally catching up on Email after vacation.
> > 
> > genhomedircon lists the entire list of passwords in order to figure out
> > where home directories are.  Not just the contents of the seusers.
> > 
> 
> Is there an implementation error in the new genhomedircon?

It still walks the entire passwd database (via getpwent()) to get the
home directory list.  The script did likewise.  So it isn't an
implementation error, but a characteristic of the genhomedircon
functionality.

BTW, the C code shouldn't be using getpwnam or getpwent - it should be
using the _r versions of those functions since it is a library.

> > At RedHat we have about 50 different root home directories
> > 
> > /home/location/dwalsh
> > 
> > We need to know this in order to have restorecon work properly.
> > 
> > Labeling of the homedir for things like .mozilla .gnome2 and .ssh
> > is still needed, but differentiating them on Roles does not make sense
> > in a distributed world.  Where if dwalsh logs into a kiosk machine he
> > might be xguest_t, on a terminal server guest_t, on his local machine
> > unconfined_t and on the security machine staff_t.  If his home directory
> > is the same on all of these, SELinux is in trouble.
> 
> So, it doesn't make sense for your specific infrastructure, that doesn't 
> mean it doesn't make sense ever. And this is a policy issue really, 
> genhomedircon just does what its told.
-- 
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: [patch 0/4] libsemanage: genhomedircon replacement

[Karl MacMillan]

On Tue, 2007-08-28 at 10:21 -0400, Joshua Brindle wrote:
> Daniel J Walsh wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> > 
> > Finally catching up on Email after vacation.
> > 
> > genhomedircon lists the entire list of passwords in order to figure out
> > where home directories are.  Not just the contents of the seusers.
> > 
> 

And this will simply not work with LDAP infrastructure - iterating over
tens-of-thousands of users on _every_ workstation is not acceptable.

> Is there an implementation error in the new genhomedircon?
> 
> > At RedHat we have about 50 different root home directories
> > 
> > /home/location/dwalsh
> > 
> > We need to know this in order to have restorecon work properly.
> > 
> > Labeling of the homedir for things like .mozilla .gnome2 and .ssh
> > is still needed, but differentiating them on Roles does not make sense
> > in a distributed world.  Where if dwalsh logs into a kiosk machine he
> > might be xguest_t, on a terminal server guest_t, on his local machine
> > unconfined_t and on the security machine staff_t.  If his home directory
> > is the same on all of these, SELinux is in trouble.
> 
> So, it doesn't make sense for your specific infrastructure, that doesn't 
> mean it doesn't make sense ever. And this is a policy issue really, 
> genhomedircon just does what its told.
> 
> 

Can we turn the question around then? Where would this behavior be
useful? And would the per-user labeling and constraints I suggested work
in those situations as an alternative? Again, we can leave genhomedircon
for all I care, I just want to have the defaults work in most
situations.

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: [patch 0/4] libsemanage: genhomedircon replacement

[Daniel J Walsh]

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

Karl MacMillan wrote:
> On Tue, 2007-08-28 at 10:21 -0400, Joshua Brindle wrote:
>> Daniel J Walsh wrote:
>>> -----BEGIN PGP SIGNED MESSAGE-----
>>> Hash: SHA1
>>>
>>> Finally catching up on Email after vacation.
>>>
>>> genhomedircon lists the entire list of passwords in order to figure out
>>> where home directories are.  Not just the contents of the seusers.
>>>
> 
> And this will simply not work with LDAP infrastructure - iterating over
> tens-of-thousands of users on _every_ workstation is not acceptable.
> 
>> Is there an implementation error in the new genhomedircon?
>>
>>> At RedHat we have about 50 different root home directories
>>>
>>> /home/location/dwalsh
>>>
>>> We need to know this in order to have restorecon work properly.
>>>
>>> Labeling of the homedir for things like .mozilla .gnome2 and .ssh
>>> is still needed, but differentiating them on Roles does not make sense
>>> in a distributed world.  Where if dwalsh logs into a kiosk machine he
>>> might be xguest_t, on a terminal server guest_t, on his local machine
>>> unconfined_t and on the security machine staff_t.  If his home directory
>>> is the same on all of these, SELinux is in trouble.
>> So, it doesn't make sense for your specific infrastructure, that doesn't 
>> mean it doesn't make sense ever. And this is a policy issue really, 
>> genhomedircon just does what its told.
>>
>>
> 
> Can we turn the question around then? Where would this behavior be
> useful? And would the per-user labeling and constraints I suggested work
> in those situations as an alternative? Again, we can leave genhomedircon
> for all I care, I just want to have the defaults work in most
> situations.
> 
> Karl
> 
> 
I believe ldap will stop you from returning the entire database anyways,
 Since it is threshold limited.  I had bugreports of genhomedircon
taking forever to run with large password database > 100,000.  This is
where the compiling of the regex saved tons of time.

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

iD8DBQFG1E9SrlYvE4MpobMRAl+BAKCJ+tDpVFIo2e+TPzbCOBhqKzV/pwCgzlOY
ILOHuv1SxKFdxSVEh+yjOc0=
=hEyU
-----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: [patch 0/4] libsemanage: genhomedircon replacement

[Stephen Smalley]

On Tue, 2007-08-28 at 12:37 -0400, Daniel J Walsh wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Karl MacMillan wrote:
> > On Tue, 2007-08-28 at 10:21 -0400, Joshua Brindle wrote:
> >> Daniel J Walsh wrote:
> >>> -----BEGIN PGP SIGNED MESSAGE-----
> >>> Hash: SHA1
> >>>
> >>> Finally catching up on Email after vacation.
> >>>
> >>> genhomedircon lists the entire list of passwords in order to figure out
> >>> where home directories are.  Not just the contents of the seusers.
> >>>
> > 
> > And this will simply not work with LDAP infrastructure - iterating over
> > tens-of-thousands of users on _every_ workstation is not acceptable.
> > 
> >> Is there an implementation error in the new genhomedircon?
> >>
> >>> At RedHat we have about 50 different root home directories
> >>>
> >>> /home/location/dwalsh
> >>>
> >>> We need to know this in order to have restorecon work properly.
> >>>
> >>> Labeling of the homedir for things like .mozilla .gnome2 and .ssh
> >>> is still needed, but differentiating them on Roles does not make sense
> >>> in a distributed world.  Where if dwalsh logs into a kiosk machine he
> >>> might be xguest_t, on a terminal server guest_t, on his local machine
> >>> unconfined_t and on the security machine staff_t.  If his home directory
> >>> is the same on all of these, SELinux is in trouble.
> >> So, it doesn't make sense for your specific infrastructure, that doesn't 
> >> mean it doesn't make sense ever. And this is a policy issue really, 
> >> genhomedircon just does what its told.
> >>
> >>
> > 
> > Can we turn the question around then? Where would this behavior be
> > useful? And would the per-user labeling and constraints I suggested work
> > in those situations as an alternative? Again, we can leave genhomedircon
> > for all I care, I just want to have the defaults work in most
> > situations.
> > 
> > Karl
> > 
> > 
> I believe ldap will stop you from returning the entire database anyways,
>  Since it is threshold limited.  I had bugreports of genhomedircon
> taking forever to run with large password database > 100,000.  This is
> where the compiling of the regex saved tons of time.

Looking at the genhomedircon code, it seems that the only reason
genhomedircon walks the entire user database is to try to find all home
directory path prefixes in order to generate appropriate default
patterns for ordinary user_t users, and that this behavior could be
disabled with the genhomedircon script by passing --nopasswd or -n to
the script, in which case it would only use the default home directory
prefixes defined by /etc/default/useradd and /etc/libuser.conf plus the
hardcoded defaults of /home and /export/home.  In the libsemanage
re-implementation of genhomedircon, this can still be specified by the
caller, but there isn't presently a way to set the desired value in
semanage.conf right now.

So, the passwd walk has nothing to do with per-role labeling of user
home directories but rather is just about discovering home directory
locations for default labeling, and you need it if you want to ensure
that all user home directories are labeled with appropriate types even
if they all use the same set of types.  So what is your solution again?

-- 
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: [patch 0/4] libsemanage: genhomedircon replacement

[Karl MacMillan]

On Thu, 2007-09-06 at 14:51 -0400, Stephen Smalley wrote:
> On Tue, 2007-08-28 at 12:37 -0400, Daniel J Walsh wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> > 
> > Karl MacMillan wrote:
> > > On Tue, 2007-08-28 at 10:21 -0400, Joshua Brindle wrote:
> > >> Daniel J Walsh wrote:
> > >>> -----BEGIN PGP SIGNED MESSAGE-----
> > >>> Hash: SHA1
> > >>>
> > >>> Finally catching up on Email after vacation.
> > >>>
> > >>> genhomedircon lists the entire list of passwords in order to figure out
> > >>> where home directories are.  Not just the contents of the seusers.
> > >>>
> > > 
> > > And this will simply not work with LDAP infrastructure - iterating over
> > > tens-of-thousands of users on _every_ workstation is not acceptable.
> > > 
> > >> Is there an implementation error in the new genhomedircon?
> > >>
> > >>> At RedHat we have about 50 different root home directories
> > >>>
> > >>> /home/location/dwalsh
> > >>>
> > >>> We need to know this in order to have restorecon work properly.
> > >>>
> > >>> Labeling of the homedir for things like .mozilla .gnome2 and .ssh
> > >>> is still needed, but differentiating them on Roles does not make sense
> > >>> in a distributed world.  Where if dwalsh logs into a kiosk machine he
> > >>> might be xguest_t, on a terminal server guest_t, on his local machine
> > >>> unconfined_t and on the security machine staff_t.  If his home directory
> > >>> is the same on all of these, SELinux is in trouble.
> > >> So, it doesn't make sense for your specific infrastructure, that doesn't 
> > >> mean it doesn't make sense ever. And this is a policy issue really, 
> > >> genhomedircon just does what its told.
> > >>
> > >>
> > > 
> > > Can we turn the question around then? Where would this behavior be
> > > useful? And would the per-user labeling and constraints I suggested work
> > > in those situations as an alternative? Again, we can leave genhomedircon
> > > for all I care, I just want to have the defaults work in most
> > > situations.
> > > 
> > > Karl
> > > 
> > > 
> > I believe ldap will stop you from returning the entire database anyways,
> >  Since it is threshold limited.  I had bugreports of genhomedircon
> > taking forever to run with large password database > 100,000.  This is
> > where the compiling of the regex saved tons of time.
> 
> Looking at the genhomedircon code, it seems that the only reason
> genhomedircon walks the entire user database is to try to find all home
> directory path prefixes in order to generate appropriate default
> patterns for ordinary user_t users, and that this behavior could be
> disabled with the genhomedircon script by passing --nopasswd or -n to
> the script, in which case it would only use the default home directory
> prefixes defined by /etc/default/useradd and /etc/libuser.conf plus the
> hardcoded defaults of /home and /export/home.  In the libsemanage
> re-implementation of genhomedircon, this can still be specified by the
> caller, but there isn't presently a way to set the desired value in
> semanage.conf right now.
> 
> So, the passwd walk has nothing to do with per-role labeling of user
> home directories but rather is just about discovering home directory
> locations for default labeling, and you need it if you want to ensure
> that all user home directories are labeled with appropriate types even
> if they all use the same set of types.  So what is your solution again?
> 

Interesting - thanks for unwinding this. It seems _much_ more reasonable
to provide a mechanism for adding home directory locations manually via
semanage.

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: [patch 0/4] libsemanage: genhomedircon replacement

[Daniel J Walsh]

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

Karl MacMillan wrote:
> On Thu, 2007-09-06 at 14:51 -0400, Stephen Smalley wrote:
>> On Tue, 2007-08-28 at 12:37 -0400, Daniel J Walsh wrote:
>>> -----BEGIN PGP SIGNED MESSAGE-----
>>> Hash: SHA1
>>>
>>> Karl MacMillan wrote:
>>>> On Tue, 2007-08-28 at 10:21 -0400, Joshua Brindle wrote:
>>>>> Daniel J Walsh wrote:
>>>>>> -----BEGIN PGP SIGNED MESSAGE-----
>>>>>> Hash: SHA1
>>>>>>
>>>>>> Finally catching up on Email after vacation.
>>>>>>
>>>>>> genhomedircon lists the entire list of passwords in order to figure out
>>>>>> where home directories are.  Not just the contents of the seusers.
>>>>>>
>>>> And this will simply not work with LDAP infrastructure - iterating over
>>>> tens-of-thousands of users on _every_ workstation is not acceptable.
>>>>
>>>>> Is there an implementation error in the new genhomedircon?
>>>>>
>>>>>> At RedHat we have about 50 different root home directories
>>>>>>
>>>>>> /home/location/dwalsh
>>>>>>
>>>>>> We need to know this in order to have restorecon work properly.
>>>>>>
>>>>>> Labeling of the homedir for things like .mozilla .gnome2 and .ssh
>>>>>> is still needed, but differentiating them on Roles does not make sense
>>>>>> in a distributed world.  Where if dwalsh logs into a kiosk machine he
>>>>>> might be xguest_t, on a terminal server guest_t, on his local machine
>>>>>> unconfined_t and on the security machine staff_t.  If his home directory
>>>>>> is the same on all of these, SELinux is in trouble.
>>>>> So, it doesn't make sense for your specific infrastructure, that doesn't 
>>>>> mean it doesn't make sense ever. And this is a policy issue really, 
>>>>> genhomedircon just does what its told.
>>>>>
>>>>>
>>>> Can we turn the question around then? Where would this behavior be
>>>> useful? And would the per-user labeling and constraints I suggested work
>>>> in those situations as an alternative? Again, we can leave genhomedircon
>>>> for all I care, I just want to have the defaults work in most
>>>> situations.
>>>>
>>>> Karl
>>>>
>>>>
>>> I believe ldap will stop you from returning the entire database anyways,
>>>  Since it is threshold limited.  I had bugreports of genhomedircon
>>> taking forever to run with large password database > 100,000.  This is
>>> where the compiling of the regex saved tons of time.
>> Looking at the genhomedircon code, it seems that the only reason
>> genhomedircon walks the entire user database is to try to find all home
>> directory path prefixes in order to generate appropriate default
>> patterns for ordinary user_t users, and that this behavior could be
>> disabled with the genhomedircon script by passing --nopasswd or -n to
>> the script, in which case it would only use the default home directory
>> prefixes defined by /etc/default/useradd and /etc/libuser.conf plus the
>> hardcoded defaults of /home and /export/home.  In the libsemanage
>> re-implementation of genhomedircon, this can still be specified by the
>> caller, but there isn't presently a way to set the desired value in
>> semanage.conf right now.
>>
>> So, the passwd walk has nothing to do with per-role labeling of user
>> home directories but rather is just about discovering home directory
>> locations for default labeling, and you need it if you want to ensure
>> that all user home directories are labeled with appropriate types even
>> if they all use the same set of types.  So what is your solution again?
>>
> 
> Interesting - thanks for unwinding this. It seems _much_ more reasonable
> to provide a mechanism for adding home directory locations manually via
> semanage.
> 
> Karl
> 

How about we run this one time at install.  And then default to off.
Allow users to regenerate if they come upon a problem or a full relable?

BTW, I thought I stated a few weeks ago the purpose of the walk was to
find home directories.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iD8DBQFG4GQjrlYvE4MpobMRAs5rAJ9Xk0bcctl7royXgf6g8LYrlq0LoQCfclof
lpfbfgWe4yu84mUxlp1uJC4=
=BsQR
-----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: [patch 0/4] libsemanage: genhomedircon replacement

[Karl MacMillan]

On Thu, 2007-09-06 at 16:33 -0400, Daniel J Walsh wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Karl MacMillan wrote:
> > On Thu, 2007-09-06 at 14:51 -0400, Stephen Smalley wrote:
> >> On Tue, 2007-08-28 at 12:37 -0400, Daniel J Walsh wrote:
> >>> -----BEGIN PGP SIGNED MESSAGE-----
> >>> Hash: SHA1
> >>>
> >>> Karl MacMillan wrote:
> >>>> On Tue, 2007-08-28 at 10:21 -0400, Joshua Brindle wrote:
> >>>>> Daniel J Walsh wrote:
> >>>>>> -----BEGIN PGP SIGNED MESSAGE-----
> >>>>>> Hash: SHA1
> >>>>>>
> >>>>>> Finally catching up on Email after vacation.
> >>>>>>
> >>>>>> genhomedircon lists the entire list of passwords in order to figure out
> >>>>>> where home directories are.  Not just the contents of the seusers.
> >>>>>>
> >>>> And this will simply not work with LDAP infrastructure - iterating over
> >>>> tens-of-thousands of users on _every_ workstation is not acceptable.
> >>>>
> >>>>> Is there an implementation error in the new genhomedircon?
> >>>>>
> >>>>>> At RedHat we have about 50 different root home directories
> >>>>>>
> >>>>>> /home/location/dwalsh
> >>>>>>
> >>>>>> We need to know this in order to have restorecon work properly.
> >>>>>>
> >>>>>> Labeling of the homedir for things like .mozilla .gnome2 and .ssh
> >>>>>> is still needed, but differentiating them on Roles does not make sense
> >>>>>> in a distributed world.  Where if dwalsh logs into a kiosk machine he
> >>>>>> might be xguest_t, on a terminal server guest_t, on his local machine
> >>>>>> unconfined_t and on the security machine staff_t.  If his home directory
> >>>>>> is the same on all of these, SELinux is in trouble.
> >>>>> So, it doesn't make sense for your specific infrastructure, that doesn't 
> >>>>> mean it doesn't make sense ever. And this is a policy issue really, 
> >>>>> genhomedircon just does what its told.
> >>>>>
> >>>>>
> >>>> Can we turn the question around then? Where would this behavior be
> >>>> useful? And would the per-user labeling and constraints I suggested work
> >>>> in those situations as an alternative? Again, we can leave genhomedircon
> >>>> for all I care, I just want to have the defaults work in most
> >>>> situations.
> >>>>
> >>>> Karl
> >>>>
> >>>>
> >>> I believe ldap will stop you from returning the entire database anyways,
> >>>  Since it is threshold limited.  I had bugreports of genhomedircon
> >>> taking forever to run with large password database > 100,000.  This is
> >>> where the compiling of the regex saved tons of time.
> >> Looking at the genhomedircon code, it seems that the only reason
> >> genhomedircon walks the entire user database is to try to find all home
> >> directory path prefixes in order to generate appropriate default
> >> patterns for ordinary user_t users, and that this behavior could be
> >> disabled with the genhomedircon script by passing --nopasswd or -n to
> >> the script, in which case it would only use the default home directory
> >> prefixes defined by /etc/default/useradd and /etc/libuser.conf plus the
> >> hardcoded defaults of /home and /export/home.  In the libsemanage
> >> re-implementation of genhomedircon, this can still be specified by the
> >> caller, but there isn't presently a way to set the desired value in
> >> semanage.conf right now.
> >>
> >> So, the passwd walk has nothing to do with per-role labeling of user
> >> home directories but rather is just about discovering home directory
> >> locations for default labeling, and you need it if you want to ensure
> >> that all user home directories are labeled with appropriate types even
> >> if they all use the same set of types.  So what is your solution again?
> >>
> > 
> > Interesting - thanks for unwinding this. It seems _much_ more reasonable
> > to provide a mechanism for adding home directory locations manually via
> > semanage.
> > 
> > Karl
> > 
> 
> How about we run this one time at install.

If they are using LDAP then it can never be run reliably.

>   And then default to off.
> Allow users to regenerate if they come upon a problem or a full relable?
> 

I think that we have to have some manual way of doing this for systems
that can't iterate over all of the password entries. I also think it
will be important to be able to exclude home directories from relabeling
when we have labeled-nfs - home directories likely shouldn't be
relabeled on every client system.

> BTW, I thought I stated a few weeks ago the purpose of the walk was to
> find home directories.

You did - it didn't occur to me however that meant the walk was needed
even if home directories weren't labeled by role.

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: [patch 0/4] libsemanage: genhomedircon replacement

[Joshua Brindle]

Stephen Smalley wrote:
> On Wed, 2007-08-15 at 16:17 -0400, Karl MacMillan wrote:
>> On Wed, 2007-08-15 at 15:56 -0400, Stephen Smalley wrote:
>>> On Wed, 2007-08-15 at 15:16 -0400, Karl MacMillan wrote:
>>>> On Wed, 2007-08-15 at 13:22 -0400, Stephen Smalley wrote:
>>>>> On Wed, 2007-08-15 at 11:57 -0400, Joshua Brindle wrote:
>>>>>> Karl MacMillan wrote:
>>>> [...]
>>>>>>> Perhaps it would be better to set it explicitly rather than
>>>>>>> based on the user. Either by giving people a way to set MLS
>>>>>>> file contexts separately from the type (which might help
>>>>>>> with MLS customization in general) or just doing a chcon on
>>>>>>> the containing home directory and having that be inherited
>>>>>>> (and not set on relabel for home directories).
>>>>>>> 
>>>>>> 
>>>>>> So... Right now its based on the policy because the home
>>>>>> directory contexts are regenerated when the policy changes,
>>>>>> you are suggesting making it more difficult to use? Right now
>>>>>> you can change someones level with semanage and restorecon -R
>>>>>> their home directory which is fairly easy. Setting the
>>>>>> contexts explicitly seems like much more burden on the local
>>>>>> admin. 
>>>>> 
>>>>> I thought genhomedircon wasn't setting the level at all (just
>>>>> using whatever is in the template, i.e. s0), and then they were
>>>>> using pam_namespace to instantiate per-level subdirs.
>>>>> 
>>>> 
>>>> Which sounds better (and safer - relabeling the level would be
>>>> questionable). However, having a mechanism to set levels separate
>>>> from type (and potentially user) sounds helpful. That way an admin
>>>> could specify, for example, that a log file should be Secret
>>>> without having to specify the type.
>>>> 
>>>>> I'm trying to understand whether the issue here is limited in
>>>>> scope to home directory labels or actually extends to the entire
>>>>> notion of per-role types (tmp files, ttys, derived program
>>>>> domains, etc).  I know that has long been an area of concern,
>>>>> not only for file relabeling but also for e.g. modules (requires
>>>>> templating that would go beyond even simple interfaces).
>>>>> 
>>>> 
>>>> I wonder too. I think that we need a means to create
>>>> limited-privilege login sessions and control movement between
>>>> privileged domains (and related domains through transitions). This
>>>> can be done with much of the current role infrastructure (see
>>>> Dan's work on guest_t and xguest_t). We can keep the process
>>>> domains without instantiating corresponding file types.
>>>> 
>>>> However, the problem with the current per-role templates is that
>>>> they are instantiated for _every_ role, which is clearly wrong for
>>>> certain types of locked-down roles. If I want a git-role that only
>>>> allows a user to login to a bash shell, execute git, and read /
>>>> write certain file types having a git_firefox_t is not desirable.
>>>> 
>>>>> genhomedircon does serve another purpose, btw - setting the
>>>>> SELinux user identity for the user's home directory. So if you
>>>>> want to do separation based on SELinux user via constraints, you
>>>>> still need a mechanism for getting the user home directories to
>>>>> have the right SELinux user identity.
>>>>> 
>>>> 
>>>> I have two suggestions (which may be totally off-base):
>>>> 
>>>> 1) Remove the selinux user concept entirely and merge it with the
>>>> DAC user identities. We would simply preserve the role
>>>> authorizations and allow constraints on the dac users (there are
>>>> some interesting details in there I know). The constraints could
>>>> be limited to user equality / inequality and not refer
> to specific users to simplify things.
>>> 
>>> By remove/merge, do you mean just use the Linux username as the
>>> SELinux user identity, like we used to do before seusers?
>  You can
>>> even do that today just by removing seusers or making it empty.  The
>>> problem with that approach I thought was that it required
>>> regenerating and loading kernel policy each time we add or remove a
>>> Linux user. 
>>> 
>> 
>> No, I mean removing the separate user identity entirely and allowing
>> selinux to directly use the linux user identity where appropriate
>> (e.g., for constraints). This may be an awful idea, it's just that we
>> abandoned
> 
> s/may be/is/
> 
>> SELinux knowledge of individual users because of scalability problems
>> (which seems somewhat unfortunate) and added a somewhat redundant
>> level of indirection. Allowing direct interaction with the linux user
>> identity would solve the scalability while giving selinux a chance to
>> have policy around individual users.
> 
> It isn't quite redundant.  Today the SELinux user is an
> "authorized role set", while the role field indicates the
> active role.  So it still functions as a bound on what roles
> are reachable by the user, and means that newrole isn't
> completely trusted (can't jump to an arbitrary role, but only
> to one in the "authorized role set" identified by the SELinux user).
> 
> If we gave that up, then newrole would be a completely
> trusted program, i.e. it would fully adjudicate what roles
> can be entered by what users.
> 
> The Linux uid is less useful to us, as we certainly don't
> want to encode uids (integers) into the SELinux policy, so
> defining user-role authorizations based on Linux uid in
> kernel policy isn't going to be workable.
> 

We don't have to encode uids into the policy, it can just be part of the
constraint language:

constrain dir_file_class_set { read write execute } 
( uid1 == uid2 );



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

[patch 1/4] libsemanage: genhomedircon initial cleanup

[tmiller]

Does a series of simple cleanups to make way for the new
genhomedircon.
 
Index: selinux/libsemanage/src/semanage_store.c
===================================================================
--- selinux.orig/libsemanage/src/semanage_store.c
+++ selinux/libsemanage/src/semanage_store.c
@@ -1008,14 +1008,15 @@ static int semanage_install_active(seman
 	const char *active_fc = semanage_path(SEMANAGE_ACTIVE, SEMANAGE_FC);
 	const char *active_fc_loc =
 	    semanage_path(SEMANAGE_ACTIVE, SEMANAGE_FC_LOCAL);
-	const char *active_hd =
-	    semanage_path(SEMANAGE_ACTIVE, SEMANAGE_HOMEDIR_TMPL);
 	const char *active_seusers =
 	    semanage_path(SEMANAGE_ACTIVE, SEMANAGE_SEUSERS);
 	const char *active_nc = semanage_path(SEMANAGE_ACTIVE, SEMANAGE_NC);
+	const char *active_fc_hd =
+	    semanage_path(SEMANAGE_ACTIVE, SEMANAGE_FC_HOMEDIRS);
 
 	const char *running_fc = selinux_file_context_path();
 	const char *running_fc_loc = selinux_file_context_local_path();
+	const char *running_fc_hd = selinux_file_context_homedir_path();
 	const char *running_hd = selinux_homedir_context_path();
 	const char *running_policy = selinux_binary_policy_path();
 	const char *running_seusers = selinux_usersconf_path();
@@ -1027,14 +1028,15 @@ static int semanage_install_active(seman
 	 * POLICYTYPE and should probably be done in the future. */
 	char store_fc[PATH_MAX];
 	char store_fc_loc[PATH_MAX];
-	char store_hd[PATH_MAX];
 	char store_pol[PATH_MAX];
 	char store_seusers[PATH_MAX];
 	char store_nc[PATH_MAX];
+	char store_fc_hd[PATH_MAX];
 
 	len = strlen(really_active_store);
 	running_fc += len;
 	running_fc_loc += len;
+	running_fc_hd += len;
 	running_hd += len;
 	running_policy += len;
 	running_seusers += len;
@@ -1055,9 +1057,10 @@ static int semanage_install_active(seman
 		goto cleanup;
 	}
 
-	snprintf(store_hd, PATH_MAX, "%s%s", storepath, running_hd);
-	if (semanage_copy_file(active_hd, store_hd, sh->conf->file_mode) == -1) {
-		ERR(sh, "Could not copy %s to %s.", active_hd, store_hd);
+	snprintf(store_fc_hd, PATH_MAX, "%s%s", storepath, running_fc_hd);
+	if (semanage_copy_file(active_fc_hd, store_fc_hd, sh->conf->file_mode)
+	    == -1) {
+		ERR(sh, "Could not copy %s to %s.", active_fc_hd, store_fc_hd);
 		goto cleanup;
 	}
 
@@ -1197,6 +1200,10 @@ static int semanage_commit_sandbox(seman
 		retval = -1;
 		goto cleanup;
 	}
+
+	/* clean up some files from the sandbox before install */
+	/* remove homedir_template from sandbox */
+
 	if (rename(sandbox, active) == -1) {
 		ERR(sh, "Error while renaming %s to %s.", sandbox, active);
 		/* note that if an error occurs during the next

-- 

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

[patch 2/4] libsemanage: genhomedircon replacement

[tmiller]

Remove python script genhomedircon from libsemanage and replace
with C functionality.

Note: This code fixes a bug in the orignal genhomedircon python script; the
following two lines are added to the file contexts whereas the old
genhomedircon would not add them: 

/tmp/\.exchange-.*(/.*)?      user_u:object_r:user_evolution_exchange_tmp_t:s0
/tmp/\.exchange-root(/.*)?    root:object_r:user_evolution_exchange_tmp_t:s0

Index: selinux/libselinux/src/file_path_suffixes.h
===================================================================
--- selinux.orig/libselinux/src/file_path_suffixes.h
+++ selinux/libselinux/src/file_path_suffixes.h
@@ -16,6 +16,6 @@ S_(BINPOLICY, "/policy/policy")
     S_(SEUSERS, "/seusers")
     S_(TRANSLATIONS, "/setrans.conf")
     S_(NETFILTER_CONTEXTS, "/contexts/netfilter_contexts")
-    S_(FILE_CONTEXTS_HOMEDIR, "/contexts/files/file_contexts.homedir")
+    S_(FILE_CONTEXTS_HOMEDIR, "/contexts/files/file_contexts.homedirs")
     S_(FILE_CONTEXTS_LOCAL, "/contexts/files/file_contexts.local")
     S_(X_CONTEXTS, "/contexts/x_contexts")
Index: selinux/libsemanage/src/semanage_store.c
===================================================================
--- selinux.orig/libsemanage/src/semanage_store.c
+++ selinux/libsemanage/src/semanage_store.c
@@ -34,6 +34,7 @@ typedef struct dbase_policydb dbase_t;
 #include "semanage_store.h"
 #include "database_policydb.h"
 #include "handle.h"
+#include "genhomedircon.h"
 
 #include <selinux/selinux.h>
 #include <sepol/policydb.h>
@@ -110,6 +111,7 @@ static const char *semanage_sandbox_path
 	"/seusers.final",
 	"/users_extra",
 	"/netfilter_contexts",
+	"/file_contexts.homedirs",
 };
 
 /* A node used in a linked list of file contexts; used for sorting.
@@ -1264,15 +1266,15 @@ int semanage_install_sandbox(semanage_ha
 		goto cleanup;
 	}
 
-	if ((commit_num = semanage_commit_sandbox(sh)) < 0) {
-		retval = commit_num;
+	if ((retval =
+	     semanage_genhomedircon(sh, 1)) != 0) {
+		ERR(sh, "semanage_genhomedircon returned error code %d.",
+		    retval);
 		goto cleanup;
 	}
 
-	if ((retval =
-	     semanage_exec_prog(sh, sh->conf->genhomedircon,
-				sh->conf->store_path, "")) != 0) {
-		ERR(sh, "genhomedircon returned error code %d.", retval);
+	if ((commit_num = semanage_commit_sandbox(sh)) < 0) {
+		retval = commit_num;
 		goto cleanup;
 	}
 
Index: selinux/libsemanage/src/semanage_store.h
===================================================================
--- selinux.orig/libsemanage/src/semanage_store.h
+++ selinux/libsemanage/src/semanage_store.h
@@ -57,6 +57,7 @@ enum semanage_sandbox_defs {
 	SEMANAGE_SEUSERS,
 	SEMANAGE_USERS_EXTRA,
 	SEMANAGE_NC,
+	SEMANAGE_FC_HOMEDIRS,
 	SEMANAGE_STORE_NUM_PATHS
 };
 
Index: selinux/libsemanage/src/genhomedircon.c
===================================================================
--- /dev/null
+++ selinux/libsemanage/src/genhomedircon.c
@@ -0,0 +1,719 @@
+/* Author: Mark Goldman   <mgoldman@tresys.com>
+ * 			Paul Rosenfeld	<prosenfeld@tresys.com>
+ *
+ * Copyright (C) 2007 Tresys Technology, LLC
+ *
+ *  This library is free software; you can redistribute it and/or modify
+ *  it under the terms of the GNU Lesser General Public License as
+ *  published by the Free Software Foundation; either version 2.1 of the
+ *  License, or (at your option) any later version.
+ *
+ *  This library is distributed in the hope that it will be useful, but
+ *  WITHOUT ANY WARRANTY; without even the implied warranty of
+ *  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ *  Lesser General Public License for more details.
+ *
+ *  You should have received a copy of the GNU Lesser General Public
+ *  License along with this library; if not, write to the Free Software
+ *  Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA
+ *  02110-1301  USA
+ */
+
+#include <semanage/handle.h>
+#include <semanage/seusers_policy.h>
+#include <semanage/users_policy.h>
+#include <semanage/user_record.h>
+#include "semanage_store.h"
+#include "seuser_internal.h"
+#include "debug.h"
+
+#include "utilities.h"
+#include "genhomedircon.h"
+#include <ustr.h>
+
+#include <assert.h>
+#include <limits.h>
+#include <stdio.h>
+#include <stdlib.h>
+#include <string.h>
+#include <sys/types.h>
+#include <sys/stat.h>
+#include <fcntl.h>
+#include <pwd.h>
+#include <errno.h>
+
+/* paths used in get_home_dirs() */
+#define PATH_ETC_USERADD "/etc/default/useradd"
+#define PATH_ETC_LIBUSER "/etc/libuser.conf"
+#define PATH_DEFAULT_HOME "/home"
+#define PATH_EXPORT_HOME "/export/home"
+#define PATH_ETC_LOGIN_DEFS "/etc/login.defs"
+
+/* other paths */
+#define PATH_SHELLS_FILE "/etc/shells"
+#define PATH_NOLOGIN_SHELL "/sbin/nologin"
+
+/* comments written to context file */
+#define COMMENT_FILE_CONTEXT_HEADER "#\n#\n# " \
+			"User-specific file contexts, generated via libsemanage\n" \
+			"# use semanage command to manage system users to change" \
+			" the file_context\n#\n#\n"
+
+#define COMMENT_USER_HOME_CONTEXT "\n\n#\n# Home Context for user %s" \
+			"\n#\n\n"
+
+/* placeholders used in the template file
+   which are searched for and replaced */
+#define TEMPLATE_HOME_ROOT "HOME_ROOT"
+#define TEMPLATE_HOME_DIR "HOME_DIR"
+#define TEMPLATE_USER "USER"
+#define TEMPLATE_ROLE "ROLE"
+#define TEMPLATE_SEUSER "system_u"
+
+#define FALLBACK_USER "user_u"
+#define FALLBACK_USER_PREFIX "user"
+#define DEFAULT_LOGIN "__default__"
+
+typedef struct {
+	const char *fcfilepath;
+	int usepasswd;
+	const char *homedir_template_path;
+	semanage_handle_t *h_semanage;
+} genhomedircon_settings_t;
+
+typedef struct user_entry {
+	char *name;
+	char *sename;
+	char *prefix;
+	char *home;
+	struct user_entry *next;
+} genhomedircon_user_entry_t;
+
+typedef struct {
+	const char *search_for;
+	const char *replace_with;
+} replacement_pair_t;
+
+static semanage_list_t *default_shell_list(void)
+{
+	semanage_list_t *list = NULL;
+
+	if (semanage_list_push(&list, "/bin/csh")
+	    || semanage_list_push(&list, "/bin/tcsh")
+	    || semanage_list_push(&list, "/bin/ksh")
+	    || semanage_list_push(&list, "/bin/bsh")
+	    || semanage_list_push(&list, "/bin/ash")
+	    || semanage_list_push(&list, "/usr/bin/ksh")
+	    || semanage_list_push(&list, "/usr/bin/pdksh")
+	    || semanage_list_push(&list, "/bin/zsh")
+	    || semanage_list_push(&list, "/bin/sh")
+	    || semanage_list_push(&list, "/bin/bash"))
+		goto fail;
+
+	return list;
+
+      fail:
+	semanage_list_destroy(&list);
+	return NULL;
+}
+
+static semanage_list_t *get_shell_list(void)
+{
+	FILE *shells;
+	char *temp = NULL;
+	semanage_list_t *list = NULL;
+	size_t buff_len = 0;
+
+	shells = fopen(PATH_SHELLS_FILE, "r");
+	if (!shells)
+		return default_shell_list();
+	while (getline(&temp, &buff_len, shells) >= 0) {
+		if (strcmp(temp, PATH_NOLOGIN_SHELL)) {
+			if (semanage_list_push(&list, temp)) {
+				free(temp);
+				semanage_list_destroy(&list);
+				return default_shell_list();
+			}
+		}
+		free(temp);
+		buff_len = 0;
+		temp = NULL;
+	}
+
+	return list;
+}
+
+static semanage_list_t *get_home_dirs(genhomedircon_settings_t * s)
+{
+	semanage_list_t *homedir_list = NULL;
+	semanage_list_t *shells = NULL;
+	char *path = NULL;
+	size_t minuid = 0;
+	size_t minuid_set = 0;
+	size_t temp;
+	struct passwd *pwbuf;
+	struct stat buf;
+
+	shells = get_shell_list();
+	assert(shells);
+
+	path = semanage_findval(PATH_ETC_USERADD, "HOME", "=");
+	if (path && *path) {
+		if (semanage_list_push(&homedir_list, path)) {
+			free(path);
+			goto fail;
+		}
+	}
+	free(path);
+
+	path = semanage_findval(PATH_ETC_LIBUSER, "LU_HOMEDIRECTORY", "=");
+	if (path && *path) {
+		if (semanage_list_push(&homedir_list, path)) {
+			free(path);
+			goto fail;
+		}
+	}
+	free(path);
+
+	if (!homedir_list) {
+		if (semanage_list_push(&homedir_list, PATH_DEFAULT_HOME)) {
+			goto fail;
+		}
+	}
+
+	if (!stat(PATH_EXPORT_HOME, &buf)) {
+		if (S_ISDIR(buf.st_mode)) {
+			if (semanage_list_push(&homedir_list, PATH_EXPORT_HOME)) {
+				goto fail;
+			}
+		}
+	}
+
+	if (!(s->usepasswd))
+		return homedir_list;
+
+	path = semanage_findval(PATH_ETC_LOGIN_DEFS, "UID_MIN", NULL);
+	if (path && *path) {
+		temp = atoi(path);
+		if (!minuid_set || temp < minuid) {
+			minuid = temp;
+			minuid_set = 1;
+		}
+	}
+	free(path);
+
+	path = semanage_findval(PATH_ETC_LIBUSER, "LU_UIDNUMBER", "=");
+	if (path && *path) {
+		temp = atoi(path);
+		if (!minuid_set || temp < minuid) {
+			minuid = temp;
+			minuid_set = 1;
+		}
+	}
+	free(path);
+
+	if (!minuid_set) {
+		minuid = 500;
+		minuid_set = 1;
+	}
+
+	setpwent();
+	for (errno = 0; (pwbuf = getpwent()); errno = 0) {
+		if (pwbuf->pw_uid < minuid)
+			continue;
+		if (!semanage_list_find(shells, pwbuf->pw_shell))
+			continue;
+		if (strcmp(pwbuf->pw_dir, "/") == 0)
+			continue;
+		if (semanage_str_count(pwbuf->pw_dir, '/') <= 1)
+			continue;
+		if (!(path = strdup(pwbuf->pw_dir))) {
+			break;
+		}
+
+		semanage_rtrim(path, '/');
+		if (!semanage_list_find(homedir_list, path)) {
+			if (semanage_list_push(&homedir_list, path)) {
+				free(path);
+				goto fail;
+			}
+		}
+		free(path);
+	}
+
+	if (errno) {
+		WARN(s->h_semanage, "Error while fetching users.  "
+		     "Returning list so far.");
+	}
+	endpwent();
+	semanage_list_destroy(&shells);
+	if (semanage_list_sort(&homedir_list))
+		goto fail;
+
+	return homedir_list;
+
+      fail:
+	semanage_list_destroy(&homedir_list);
+	semanage_list_destroy(&shells);
+	return NULL;
+}
+
+/**
+ * @param	s	settings structure, stores various paths etc. Must never be NULL
+ * @param	out	the FILE to put all the output in.
+ * @return	0 on success
+ */
+static int write_file_context_header(genhomedircon_settings_t * s, FILE * out)
+{
+	if (fprintf(out, COMMENT_FILE_CONTEXT_HEADER) < 0) {
+		return STATUS_ERR;
+	}
+
+	return STATUS_SUCCESS;
+}
+
+/* Predicates for use with semanage_slurp_file_filter() the homedir_template
+ * file currently contains lines that serve as the template for a user's
+ * homedir.
+ *
+ * It also contains lines that are the template for the parent of a
+ * user's home directory.
+ *
+ * Currently, the only lines that apply to the the root of a user's home
+ * directory are all prefixed with the string "HOME_ROOT".  All other
+ * lines apply to a user's home directory.  If this changes the
+ * following predicates need to change to reflect that.
+ */
+static int HOME_ROOT_PRED(const char *string)
+{
+	return semanage_is_prefix(string, TEMPLATE_HOME_ROOT);
+}
+
+static int HOME_DIR_PRED(const char *string)
+{
+	return semanage_is_prefix(string, TEMPLATE_HOME_DIR);
+}
+
+static int USER_CONTEXT_PRED(const char *string)
+{
+	return (int)(strstr(string, TEMPLATE_USER) != NULL);
+}
+
+/* make_tempate
+ * @param	s	  the settings holding the paths to various files
+ * @param	pred	function pointer to function to use as filter for slurp
+ * 					file filter
+ * @return   a list of lines from the template file with inappropriate
+ *	    lines filtered out.
+ */
+static semanage_list_t *make_template(genhomedircon_settings_t * s,
+				      int (*pred) (const char *))
+{
+	FILE *template_file = NULL;
+	semanage_list_t *template_data = NULL;
+
+	template_file = fopen(s->homedir_template_path, "r");
+	if (!template_file)
+		return NULL;
+	template_data = semanage_slurp_file_filter(template_file, pred);
+	fclose(template_file);
+
+	return template_data;
+}
+
+static Ustr *replace_all(const char *str, const replacement_pair_t * repl)
+{
+	Ustr *retval = USTR_NULL;
+	int i, num_replaced = 0;
+
+	if (!str || !repl)
+		goto done;
+	if (!(retval = ustr_dup_cstr(str)))
+		goto done;
+
+	for (i = 0; repl[i].search_for; i++) {
+		num_replaced += ustr_replace_cstr(&retval, repl[i].search_for,
+						  repl[i].replace_with, 0);
+	}
+	if (!num_replaced)
+		ustr_sc_free(&retval);
+
+      done:
+	return retval;
+}
+
+static int write_home_dir_context(FILE * out, semanage_list_t * tpl,
+				  const char *user, const char *seuser,
+				  const char *home, const char *role_prefix)
+{
+	replacement_pair_t repl[] = {
+		{.search_for = TEMPLATE_SEUSER,.replace_with = seuser},
+		{.search_for = TEMPLATE_HOME_DIR,.replace_with = home},
+		{.search_for = TEMPLATE_ROLE,.replace_with = role_prefix},
+		{NULL, NULL}
+	};
+	Ustr *line = USTR_NULL;
+
+	if (fprintf(out, COMMENT_USER_HOME_CONTEXT, user) < 0)
+		return STATUS_ERR;
+
+	for (; tpl; tpl = tpl->next) {
+		line = replace_all(tpl->data, repl);
+		if (!line || !ustr_io_putfileline(&line, out))
+			goto fail;
+		ustr_sc_free(&line);
+	}
+	return STATUS_SUCCESS;
+
+      fail:
+	ustr_sc_free(&line);
+	return STATUS_ERR;
+}
+
+static int write_home_root_context(FILE * out, semanage_list_t * tpl,
+				   char *homedir)
+{
+	replacement_pair_t repl[] = {
+		{.search_for = TEMPLATE_HOME_ROOT,.replace_with = homedir},
+		{NULL, NULL}
+	};
+	Ustr *line = USTR_NULL;
+
+	for (; tpl; tpl = tpl->next) {
+		line = replace_all(tpl->data, repl);
+		if (!line || !ustr_io_putfileline(&line, out))
+			goto fail;
+		ustr_sc_free(&line);
+	}
+	return STATUS_SUCCESS;
+
+      fail:
+	ustr_sc_free(&line);
+	return STATUS_ERR;
+}
+
+static int write_user_context(FILE * out, semanage_list_t * tpl, char *user,
+			      char *seuser, char *role_prefix)
+{
+	replacement_pair_t repl[] = {
+		{.search_for = TEMPLATE_USER,.replace_with = user},
+		{.search_for = TEMPLATE_ROLE,.replace_with = role_prefix},
+		{.search_for = TEMPLATE_SEUSER,.replace_with = seuser},
+		{NULL, NULL}
+	};
+	Ustr *line = USTR_NULL;
+
+	for (; tpl; tpl = tpl->next) {
+		line = replace_all(tpl->data, repl);
+		if (!line || !ustr_io_putfileline(&line, out))
+			goto fail;
+		ustr_sc_free(&line);
+	}
+	return STATUS_SUCCESS;
+
+      fail:
+	ustr_sc_free(&line);
+	return STATUS_ERR;
+}
+
+static int user_sort_func(semanage_user_t ** arg1, semanage_user_t ** arg2)
+{
+	return strcmp(semanage_user_get_name(*arg1),
+		      semanage_user_get_name(*arg2));
+}
+
+static int name_user_cmp(char *key, semanage_user_t ** val)
+{
+	return strcmp(key, semanage_user_get_name(*val));
+}
+
+static int push_user_entry(genhomedircon_user_entry_t ** list, const char *n,
+			   const char *sen, const char *pre, const char *h)
+{
+	genhomedircon_user_entry_t *temp = NULL;
+	char *name = NULL;
+	char *sename = NULL;
+	char *prefix = NULL;
+	char *home = NULL;
+
+	temp = malloc(sizeof(genhomedircon_user_entry_t));
+	if (!temp)
+		goto cleanup;
+	name = strdup(n);
+	if (!name)
+		goto cleanup;
+	sename = strdup(sen);
+	if (!sename)
+		goto cleanup;
+	prefix = strdup(pre);
+	if (!prefix)
+		goto cleanup;
+	home = strdup(h);
+	if (!home)
+		goto cleanup;
+
+	temp->name = name;
+	temp->sename = sename;
+	temp->prefix = prefix;
+	temp->home = home;
+	temp->next = (*list);
+	(*list) = temp;
+
+	return STATUS_SUCCESS;
+
+      cleanup:
+	free(name);
+	free(sename);
+	free(prefix);
+	free(home);
+	free(temp);
+	return STATUS_ERR;
+}
+
+static void pop_user_entry(genhomedircon_user_entry_t ** list)
+{
+	genhomedircon_user_entry_t *temp;
+
+	if (!list || !(*list))
+		return;
+
+	temp = *list;
+	*list = temp->next;
+	free(temp->name);
+	free(temp->sename);
+	free(temp->prefix);
+	free(temp->home);
+	free(temp);
+}
+
+static genhomedircon_user_entry_t *get_users(genhomedircon_settings_t * s,
+					     int *errors)
+{
+	genhomedircon_user_entry_t *head = NULL;
+	semanage_seuser_t **seuser_list = NULL;
+	unsigned int nseusers = 0;
+	semanage_user_t **user_list = NULL;
+	unsigned int nusers = 0;
+	semanage_user_t **u = NULL;
+	const char *name = NULL;
+	const char *seuname = NULL;
+	const char *prefix = NULL;
+	struct passwd *pwent = NULL;
+	unsigned int i;
+	int retval;
+
+	*errors = 0;
+	retval = semanage_seuser_list(s->h_semanage, &seuser_list, &nseusers);
+	if (retval < 0 || (nseusers < 1)) {
+		/* if there are no users, this function can't do any other work */
+		return NULL;
+	}
+
+	if (semanage_user_list(s->h_semanage, &user_list, &nusers) < 0) {
+		nusers = 0;
+	}
+
+	qsort(user_list, nusers, sizeof(semanage_user_t *),
+	      (int (*)(const void *, const void *))&user_sort_func);
+
+	for (i = 0; i < nseusers; i++) {
+		name = semanage_seuser_get_name(seuser_list[i]);
+		seuname = semanage_seuser_get_sename(seuser_list[i]);
+
+		if (strcmp(seuname, FALLBACK_USER) == 0)
+			continue;
+		if (strcmp(seuname, DEFAULT_LOGIN) == 0)
+			continue;
+		if (strcmp(seuname, TEMPLATE_SEUSER) == 0)
+			continue;
+
+		/* find the user structure given the name */
+		u = bsearch(name, user_list, nusers, sizeof(semanage_user_t *),
+			    (int (*)(const void *, const void *))
+			    &name_user_cmp);
+		if (u) {
+			prefix = semanage_user_get_prefix(*u);
+		} else {
+			prefix = name;
+		}
+
+		errno = 0;
+		pwent = getpwnam(name);
+		if (!pwent) {
+			if (errno != 0) {
+				*errors = STATUS_ERR;
+				goto cleanup;
+			}
+			WARN(s->h_semanage,
+			     "user %s not in password file", name);
+			continue;
+		}
+
+		if (strcmp(pwent->pw_dir, "/") == 0) {
+			/* don't relabel / genhomdircon checked to see if root
+			 * was the user and if so, set his home directory to
+			 * /root */
+			continue;
+		}
+		if (push_user_entry(&head, name, seuname,
+				    prefix, pwent->pw_dir) != STATUS_SUCCESS) {
+			*errors = STATUS_ERR;
+			break;
+		}
+	}
+
+      cleanup:
+	if (*errors) {
+		for (; head; pop_user_entry(&head)) {
+			/* the pop function takes care of all the cleanup
+			   so the loop body is just empty */
+		}
+	}
+	for (i = 0; i < nseusers; i++) {
+		semanage_seuser_free(seuser_list[i]);
+	}
+	free(seuser_list);
+
+	for (i = 0; i < nusers; i++) {
+		semanage_user_free(user_list[i]);
+	}
+	free(user_list);
+
+	return head;
+}
+
+static int write_gen_home_dir_context(FILE * out, genhomedircon_settings_t * s,
+				      semanage_list_t * user_context_tpl,
+				      semanage_list_t * homedir_context_tpl)
+{
+	genhomedircon_user_entry_t *users;
+	int errors = 0;
+
+	users = get_users(s, &errors);
+	if (!users && errors) {
+		return STATUS_ERR;
+	}
+
+	for (; users; pop_user_entry(&users)) {
+		if (write_home_dir_context(out, homedir_context_tpl,
+					   users->name,
+					   users->sename, users->home,
+					   users->prefix)) {
+			return STATUS_ERR;
+		}
+		if (write_user_context(out, user_context_tpl, users->name,
+				       users->sename, users->prefix)) {
+			return STATUS_ERR;
+		}
+	}
+
+	return STATUS_SUCCESS;
+}
+
+/**
+ * @param	s	settings structure, stores various paths etc. Must never be NULL
+ * @param	out	the FILE to put all the output in.
+ * @return	0 on success
+ */
+static int write_context_file(genhomedircon_settings_t * s, FILE * out)
+{
+	semanage_list_t *homedirs = NULL;
+	semanage_list_t *h = NULL;
+	semanage_list_t *user_context_tpl = NULL;
+	semanage_list_t *homedir_context_tpl = NULL;
+	semanage_list_t *homeroot_context_tpl = NULL;
+	int retval = STATUS_SUCCESS;
+
+	homedirs = get_home_dirs(s);
+	if (!homedirs) {
+		WARN(s->h_semanage,
+		     "no home directories were available, exiting without writing");
+		return STATUS_ERR;	/* No homedirs so no output */
+	}
+
+	if (write_file_context_header(s, out) != STATUS_SUCCESS)
+		return STATUS_ERR;
+
+	homedir_context_tpl = make_template(s, &HOME_DIR_PRED);
+	homeroot_context_tpl = make_template(s, &HOME_ROOT_PRED);
+	user_context_tpl = make_template(s, &USER_CONTEXT_PRED);
+	if (!homedir_context_tpl || !homeroot_context_tpl || !user_context_tpl) {
+		retval = STATUS_ERR;
+		goto done;
+	}
+
+	for (h = homedirs; h; h = h->next) {
+		Ustr *temp = ustr_dup_cstr(h->data);
+
+		if (!temp || !ustr_add_cstr(&temp, "/[^/]*")) {
+			ustr_sc_free(&temp);
+			retval = STATUS_ERR;
+			goto done;
+		}
+
+		if (write_home_dir_context(out,
+					   homedir_context_tpl, FALLBACK_USER,
+					   FALLBACK_USER, ustr_cstr(temp),
+					   FALLBACK_USER_PREFIX) !=
+		    STATUS_SUCCESS) {
+			ustr_sc_free(&temp);
+			retval = STATUS_ERR;
+			goto done;
+		}
+		if (write_home_root_context(out,
+					    homeroot_context_tpl,
+					    h->data) != STATUS_SUCCESS) {
+			ustr_sc_free(&temp);
+			retval = STATUS_ERR;
+			goto done;
+		}
+
+		ustr_sc_free(&temp);
+	}
+	if (write_user_context(out, user_context_tpl,
+			       ".*", FALLBACK_USER,
+			       FALLBACK_USER_PREFIX) != STATUS_SUCCESS) {
+		retval = STATUS_ERR;
+		goto done;
+	}
+	if (write_gen_home_dir_context(out, s, user_context_tpl,
+				       homedir_context_tpl) != STATUS_SUCCESS) {
+		retval = STATUS_ERR;
+	}
+
+      done:
+	/* Cleanup */
+	semanage_list_destroy(&homedirs);
+	semanage_list_destroy(&user_context_tpl);
+	semanage_list_destroy(&homedir_context_tpl);
+	semanage_list_destroy(&homeroot_context_tpl);
+
+	return retval;
+}
+
+int semanage_genhomedircon(semanage_handle_t * sh, int usepasswd)
+{
+	genhomedircon_settings_t s;
+	FILE *out = NULL;
+	int retval = 0;
+
+	assert(sh);
+
+	s.homedir_template_path =
+	    semanage_path(SEMANAGE_TMP, SEMANAGE_HOMEDIR_TMPL);
+	s.fcfilepath = semanage_path(SEMANAGE_TMP, SEMANAGE_FC_HOMEDIRS);
+
+	s.usepasswd = usepasswd;
+	s.h_semanage = sh;
+
+	if (!(out = fopen(s.fcfilepath, "w"))) {
+		/* couldn't open output file */
+		ERR(sh, "Could not open the file_context file for writing");
+		return STATUS_ERR;
+	}
+
+	retval = write_context_file(&s, out);
+
+	fclose(out);
+	return retval;
+}
Index: selinux/libsemanage/src/genhomedircon.h
===================================================================
--- /dev/null
+++ selinux/libsemanage/src/genhomedircon.h
@@ -0,0 +1,27 @@
+/* Author: Mark Goldman   <mgoldman@tresys.com>
+ *
+ * Copyright (C) 2007 Tresys Technology, LLC
+ *
+ *  This library is free software; you can redistribute it and/or
+ *  modify it under the terms of the GNU Lesser General Public
+ *  License as published by the Free Software Foundation; either
+ *  version 2.1 of the License, or (at your option) any later version.
+ *
+ *  This library is distributed in the hope that it will be useful,
+ *  but WITHOUT ANY WARRANTY; without even the implied warranty of
+ *  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ *  Lesser General Public License for more details.
+ *
+ *  You should have received a copy of the GNU Lesser General Public
+ *  License along with this library; if not, write to the Free Software
+ *  Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA  02110-1301  USA
+ */
+
+#ifndef _SEMANAGE_GENHOMEDIRCON_H_
+#define _SEMANAGE_GENHOMEDIRCON_H_
+
+#include "utilities.h"
+
+int semanage_genhomedircon(semanage_handle_t * sh, int usepasswd);
+
+#endif
Index: selinux/libsemanage/src/utilities.c
===================================================================
--- /dev/null
+++ selinux/libsemanage/src/utilities.c
@@ -0,0 +1,310 @@
+/* Author: Mark Goldman   <mgoldman@tresys.com>
+ *			Paul Rosenfeld	<prosenfeld@tresys.com>
+ *
+ * Copyright (C) 2007 Tresys Technology, LLC
+ *
+ *  This library is free software; you can redistribute it and/or
+ *  modify it under the terms of the GNU Lesser General Public
+ *  License as published by the Free Software Foundation; either
+ *  version 2.1 of the License, or (at your option) any later version.
+ *
+ *  This library is distributed in the hope that it will be useful,
+ *  but WITHOUT ANY WARRANTY; without even the implied warranty of
+ *  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ *  Lesser General Public License for more details.
+ *
+ *  You should have received a copy of the GNU Lesser General Public
+ *  License along with this library; if not, write to the Free Software
+ *  Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA  02110-1301  USA
+ */
+#include "utilities.h"
+
+#include <errno.h>
+#include <stdio.h>
+#include <stdlib.h>
+#include <stdbool.h>
+#include <ctype.h>
+#include <string.h>
+#include <sys/types.h>
+#include <assert.h>
+#include <ustr.h>
+
+char *semanage_findval(char *file, char *var, char *delim)
+{
+	FILE *fd;
+	char *buff = NULL;
+	char *retval = NULL;
+	size_t buff_len = 0;
+
+	assert(file);
+	assert(var);
+
+	if ((fd = fopen(file, "r")) == NULL)
+		return NULL;
+
+	while (getline(&buff, &buff_len, fd) > 0) {
+		if (semanage_is_prefix(buff, var)) {
+			retval = semanage_split(buff, delim);
+			if (retval)
+				semanage_rtrim(retval, '\n');
+			break;
+		}
+	}
+	free(buff);
+	fclose(fd);
+
+	return retval;
+}
+
+bool semanage_is_prefix(const char *str, const char *prefix)
+{
+	bool retval;
+	Ustr *ustr = USTR_NULL;
+
+	if (!str) {
+		return false;
+	}
+	if (!prefix) {
+		return true;
+	}
+	if (!(ustr = ustr_dup_cstr(str))) {
+		return false;
+	}
+	retval = (ustr_srch_cstr_fwd(ustr, 0, prefix) == 1);
+	ustr_sc_free(&ustr);
+
+	return retval;
+}
+
+char *semanage_split_on_space(const char *str)
+{
+	/* as per the man page, these are the isspace() chars */
+	const char *seps = "\f\n\r\t\v ";
+	size_t slen = strlen(seps);
+	size_t off = 0, rside_len = 0;
+	char *retval = NULL;
+	Ustr *ustr = USTR_NULL, *temp = USTR_NULL;
+
+	if (!str)
+		goto done;
+	if (!(ustr = ustr_dup_cstr(str)))
+		goto done;
+	temp =
+	    ustr_split_spn_chrs(ustr, &off, seps, slen, USTR_NULL,
+				USTR_FLAG_SPLIT_DEF);
+	if (!temp)
+		goto done;
+	/* throw away the left hand side */
+	ustr_sc_free(&temp);
+
+	rside_len = ustr_len(ustr) - off;
+	temp = ustr_dup_subustr(ustr, off + 1, rside_len);
+	if (!temp)
+		goto done;
+	retval = strdup(ustr_cstr(temp));
+	ustr_sc_free(&temp);
+
+      done:
+	ustr_sc_free(&ustr);
+	return retval;
+}
+
+char *semanage_split(const char *str, const char *delim)
+{
+	Ustr *ustr = USTR_NULL, *temp = USTR_NULL;
+	size_t off = 0, rside_len = 0;
+	char *retval = NULL;
+
+	if (!str)
+		goto done;
+	if (!delim || !(*delim))
+		return semanage_split_on_space(str);
+	ustr = ustr_dup_cstr(str);
+	temp =
+	    ustr_split_cstr(ustr, &off, delim, USTR_NULL, USTR_FLAG_SPLIT_DEF);
+	if (!temp)
+		goto done;
+	/* throw away the left hand side */
+	ustr_sc_free(&temp);
+
+	rside_len = ustr_len(ustr) - off;
+
+	temp = ustr_dup_subustr(ustr, off + 1, rside_len);
+	if (!temp)
+		goto done;
+	retval = strdup(ustr_cstr(temp));
+	ustr_sc_free(&temp);
+
+      done:
+	ustr_sc_free(&ustr);
+	return retval;
+}
+
+int semanage_list_push(semanage_list_t ** list, char *data)
+{
+	semanage_list_t *temp = NULL;
+
+	if (!data)
+		return EINVAL;
+	if (!(temp = malloc(sizeof(semanage_list_t))))
+		return ENOMEM;
+
+	if (!(temp->data = strdup(data))) {
+		free(temp);
+		return ENOMEM;
+	}
+	temp->next = *list;
+	*list = temp;
+
+	return 0;
+}
+
+char *semanage_list_pop(semanage_list_t ** list)
+{
+	semanage_list_t *node = NULL;
+	char *data = NULL;
+
+	if (!list || !(*list))
+		return NULL;
+
+	node = (*list);
+	data = node->data;
+
+	(*list) = node->next;
+	free(node);
+
+	return data;
+}
+
+void semanage_list_destroy(semanage_list_t ** list)
+{
+	semanage_list_t *temp;
+
+	while ((temp = (*list))) {
+		free(temp->data);
+		(*list) = temp->next;
+		free(temp);
+	}
+}
+
+semanage_list_t *semanage_list_find(semanage_list_t * l, char *data)
+{
+	if (!data)
+		return NULL;
+	while (l && strcmp(l->data, data))
+		l = l->next;
+
+	return l;
+}
+
+int semanage_list_sort(semanage_list_t ** l)
+{
+	semanage_list_t **array = NULL;
+	semanage_list_t *temp = NULL;
+	size_t count = 0;
+	size_t i = 0;
+
+	if (!l)
+		return 0;
+
+	for (temp = *l; temp; temp = temp->next)
+		++count;
+
+	array = malloc(sizeof(semanage_list_t *) * count);
+	if (!array)
+		return ENOMEM;	/* couldn't allocate memory for sort */
+	for (temp = *l; temp; temp = temp->next) {
+		array[i++] = temp;
+	}
+
+	qsort(array, count, sizeof(semanage_list_t *),
+	      (int (*)(const void *, const void *))&semanage_cmp_plist_t);
+	for (i = 0; i < (count - 1); ++i) {
+		array[i]->next = array[i + 1];
+	}
+	array[i]->next = NULL;
+	(*l) = array[0];
+	free(array);
+
+	return 0;
+}
+
+int semanage_cmp_plist_t(const semanage_list_t ** x, const semanage_list_t ** y)
+{
+	return strcmp((*x)->data, (*y)->data);
+}
+
+int semanage_str_count(char *data, char what)
+{
+	int count = 0;
+
+	if (!data)
+		return 0;
+	while (*data) {
+		if (*data == what)
+			++count;
+		++data;
+	}
+
+	return count;
+}
+
+void semanage_rtrim(char *str, char trim_to)
+{
+	int len = 0;
+
+	if (!str)
+		return;
+	len = strlen(str);
+
+	while (len > 0) {
+		if (str[--len] == trim_to) {
+			str[len] = '\0';
+			return;
+		}
+	}
+}
+
+/* list_addafter_controlmem does *NOT* duplicate the data argument
+ * use at your own risk, I am building a list out of malloc'd memory and
+ * it is only going to get stored into this list, thus when I destroy it
+ * later I won't free a ptr twice.
+ *
+ * returns the newly created node or NULL on error
+ */
+semanage_list_t *list_addafter_controlmem(semanage_list_t * item, char *data)
+{
+	semanage_list_t *temp = malloc(sizeof(semanage_list_t));
+
+	if (!temp)
+		return NULL;
+	temp->data = data;
+	temp->next = item->next;
+	item->next = temp;
+
+	return temp;
+}
+
+semanage_list_t *semanage_slurp_file_filter(FILE * file,
+					    int (*pred) (const char *))
+{
+	semanage_list_t head;
+	semanage_list_t *current = &head;
+	char *line = NULL;
+	size_t buff_len = 0;
+
+	head.next = NULL;	/* initialize head, we aren't going to use the data */
+	while (getline(&line, &buff_len, file) >= 0) {
+		if (pred(line)) {
+			current = list_addafter_controlmem(current, line);
+			if (!current)
+				break;	/* if there was an error break out of the loop */
+		} else {
+			free(line);
+		}
+		line = NULL;
+		buff_len = 0;
+	}
+
+	return head.next;
+}
Index: selinux/libsemanage/src/utilities.h
===================================================================
--- /dev/null
+++ selinux/libsemanage/src/utilities.h
@@ -0,0 +1,138 @@
+/* Author: Mark Goldman   <mgoldman@tresys.com>
+ *
+ * Copyright (C) 2007 Tresys Technology, LLC
+ *
+ *  This library is free software; you can redistribute it and/or
+ *  modify it under the terms of the GNU Lesser General Public
+ *  License as published by the Free Software Foundation; either
+ *  version 2.1 of the License, or (at your option) any later version.
+ *
+ *  This library is distributed in the hope that it will be useful,
+ *  but WITHOUT ANY WARRANTY; without even the implied warranty of
+ *  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ *  Lesser General Public License for more details.
+ *
+ *  You should have received a copy of the GNU Lesser General Public
+ *  License along with this library; if not, write to the Free Software
+ *  Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA  02110-1301  USA
+ */
+
+/* This file contains helper functions that are loosely based off of what is
+ * available from the python script genhomedircon.  Also this file contains
+ * c implementations of a couple of python functions so that genhomedircon will
+ * look/act like the python script.
+ */
+#ifndef _SEMANAGE_UTILITIES_H_
+#define _SEMANAGE_UTILITIES_H_
+
+#include <stdio.h>
+#include <stdbool.h>
+
+#if defined(__GNUC__) && !defined(__STRICT_ANSI__)
+#define WARN_UNUSED \
+	__attribute__ ((__warn_unused_result__))
+#else
+# define WARN_UNUSED		/* nothing */
+#endif
+
+typedef struct list {
+	char *data;
+	struct list *next;
+} semanage_list_t;
+
+/**
+ * @param file  the path to the file to look for a variable in
+ * @param var   the variable that you want the value of
+ * @param delim the value that separates the part you care about from the part
+ *	       that you don't.
+ * @return for the first instance of var in the file, returns everything after
+ *	   delim.
+ *	   returns "" if not found IE if(*(semanage_findval(f,v,d)) == '\0'){
+ *					  printf("%s not found in file", v);
+ *				       }
+ *
+ *	   NULL for error (out of memory, etc)
+ */
+char *semanage_findval(char *file, char *var, char *delim) WARN_UNUSED;
+
+/**
+ * @param str   string to test
+ * @param	 val   prefix
+ * @return  1 if val is the prefix of str
+ *	    0 if val is not the prefix of str
+ *
+ * note: if str == NULL, returns false
+ *	 if val == NULL, returns true --nothing can always be the prefix of
+ *				        something
+ *	 if (*val) == "" returns true same as above.
+ */
+bool semanage_is_prefix(const char *str, const char *val) WARN_UNUSED;
+
+/**
+ * @param str   the string to semanage_split
+ * @return     malloc'd string after the first run of charachters that aren't whitespace
+ */
+char *semanage_split_on_space(const char *str) WARN_UNUSED;
+
+/**
+ * @param	 str   the string to semanage_split
+ * @param	 delim the string delimiter.  NOT a set of charachters that can be
+ *	       a delimiter.
+ *	       if *delim == '\0' behaves as semanage_splitOnSpace()
+ * @return   a ptr to the first charachter past the delimiter.
+ *	    if delim doesn't appear in the string, returns a ptr to the
+ *	    trailing null in the string
+ */
+char *semanage_split(const char *str, const char *delim) WARN_UNUSED;
+
+/* linked list string functions
+ * Functions allocate memory.  Must be free'd with
+ * either semanage_list_pop until list == NULL or semanage_list_destroy()
+ */
+int semanage_list_push(semanage_list_t ** list, char *data) WARN_UNUSED;
+char *semanage_list_pop(semanage_list_t ** list);
+void semanage_list_destroy(semanage_list_t ** list);
+semanage_list_t *semanage_list_find(semanage_list_t * l,
+				    char *data) WARN_UNUSED;
+int semanage_list_sort(semanage_list_t ** l) WARN_UNUSED;
+/* function to compare 2 semanage_list_t nodes,
+ * returns strcmp(x->data, y->data)
+ * used internally by semanage_list_sort()
+ */
+int semanage_cmp_plist_t(const semanage_list_t ** x,
+			 const semanage_list_t ** y);
+/**
+ * @param      data a target string
+ * @param      what  a charachter
+ * @returns    the number of times the char appears in the string
+ */
+int semanage_str_count(char *data, char what);
+/**
+ * @param      - a string
+ * @param            the charachter to trim to
+ * @return   - mangles the string, converting the first
+ *             occurrance of the charachter to a '\0' from
+ *             the end of the string.
+ */
+void semanage_rtrim(char *str, char trim_to);
+
+/**
+ * @param data    some string
+ * @return  modifies the string such that the first whitespace char becomes
+ *	    '\0', ending the string.
+ */
+void semanage_keep_until_space(char *data);
+
+/**
+ * @param    file    - an open FILE to read from
+ * @param    pred    - a function taking a string that
+ *                    returns 1 if the string should be
+ *                    kept and 0 otherwise
+ * @return  a list of lines from the file (empty lines become
+ *          empty strings) in the file order where pred(line)
+ *          returns > 0
+ */
+semanage_list_t *semanage_slurp_file_filter(FILE * file,
+					    int (*pred) (const char *))
+    WARN_UNUSED;
+#endif
Index: selinux/libsemanage/src/Makefile
===================================================================
--- selinux.orig/libsemanage/src/Makefile
+++ selinux/libsemanage/src/Makefile
@@ -54,7 +54,7 @@ $(LIBA): $(OBJS)
 	ranlib $@
 
 $(LIBSO): $(LOBJS)
-	$(CC) $(LDFLAGS) -shared -o $@ $^ -lsepol -lselinux -L$(LIBDIR) -Wl,-soname,$(LIBSO),--version-script=libsemanage.map,-z,defs
+	$(CC) $(LDFLAGS) -shared -o $@ $^ -lsepol -lselinux -lustr -L$(LIBDIR) -Wl,-soname,$(LIBSO),--version-script=libsemanage.map,-z,defs
 	ln -sf $@ $(TARGET)
 
 conf-scan.c: conf-scan.l conf-parse.h

-- 

--
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: [patch 2/4] libsemanage: genhomedircon replacement

[Stephen Smalley]

On Wed, 2007-08-15 at 16:44 -0400, tmiller@tresys.com wrote:
> plain text document attachment (genhomedircon-replacement-initial)
> Remove python script genhomedircon from libsemanage and replace
> with C functionality.
> 
> Note: This code fixes a bug in the orignal genhomedircon python script; the
> following two lines are added to the file contexts whereas the old
> genhomedircon would not add them: 
> 
> /tmp/\.exchange-.*(/.*)?      user_u:object_r:user_evolution_exchange_tmp_t:s0
> /tmp/\.exchange-root(/.*)?    root:object_r:user_evolution_exchange_tmp_t:s0

It'd be nice to get a separate bug fix patch for that in the python
genhomedircon for stable.

I just tried running the patched libsemanage and had it regenerate
(semodule -B) on targeted, strict, and mls.  Offhand, I notice that:
- there is lots of extraneous whitespace lines,
- under strict and mls, it botched the entries for me (added via
semanage login -a -s staff_u sds previously), using sds_home_t instead
of staff_home_t.  Oops!
- it kept some entries that old genhomedircon was dropping, as you noted
above (bad genhomedircon, bad!).

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

[patch 3/4] libsemanage: test functions

[tmiller]

Test functions for libsemanage/src/utilities.c and
libsemanage/src/utilities.h

Index: selinux/libsemanage/tests/libsemanage-tests.c
===================================================================
--- selinux.orig/libsemanage/tests/libsemanage-tests.c
+++ selinux/libsemanage/tests/libsemanage-tests.c
@@ -20,6 +20,7 @@
  */
 
 #include "test_semanage_store.h"
+#include "test_utilities.h"
 
 #include <CUnit/Basic.h>
 #include <CUnit/Console.h>
@@ -55,6 +56,7 @@ static int do_tests(int interactive, int
 		return CU_get_error();
 
 	DECLARE_SUITE(semanage_store);
+	DECLARE_SUITE(semanage_utilities);
 
 	if (verbose)
 		CU_basic_set_mode(CU_BRM_VERBOSE);
Index: selinux/libsemanage/tests/Makefile
===================================================================
--- selinux.orig/libsemanage/tests/Makefile
+++ selinux/libsemanage/tests/Makefile
@@ -13,7 +13,7 @@ EXECUTABLE = libsemanage-tests
 CC = gcc
 CFLAGS = -c -g -o0 -Wall -W -Wundef -Wmissing-noreturn -Wmissing-format-attribute -Wno-unused-parameter
 INCLUDE = -I$(TESTSRC) -I$(TESTSRC)/../include/semanage
-LDFLAGS = -lcunit
+LDFLAGS = -lcunit -lustr
 OBJECTS = $(SOURCES:.c=.o) 
 
 all: $(EXECUTABLE) 
Index: selinux/libsemanage/tests/test_utilities.c
===================================================================
--- /dev/null
+++ selinux/libsemanage/tests/test_utilities.c
@@ -0,0 +1,285 @@
+/* Authors: Mark Goldman <mgoldman@tresys.com>
+ *
+ * Copyright (C) 2007 Tresys Technology, LLC
+ *
+ *  This library is free software; you can redistribute it and/or
+ *  modify it under the terms of the GNU Lesser General Public
+ *  License as published by the Free Software Foundation; either
+ *  version 2.1 of the License, or (at your option) any later version.
+ *
+ *  This library is distributed in the hope that it will be useful,
+ *  but WITHOUT ANY WARRANTY; without even the implied warranty of
+ *  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ *  Lesser General Public License for more details.
+ *
+ *  You should have received a copy of the GNU Lesser General Public
+ *  License along with this library; if not, write to the Free Software
+ *  Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA  02110-1301  USA
+ */
+
+/*  The purpose of this file is to provide unit tests of the functions in:
+ *
+ *  libsemanage/src/utilities.c
+ *
+ */
+
+#include <CUnit/Basic.h>
+#include <CUnit/Console.h>
+#include <CUnit/TestDB.h>
+
+#include <utilities.h>
+#include <stdio.h>
+#include <getopt.h>
+#include <stdlib.h>
+#include <string.h>
+#include <unistd.h>
+
+void test_semanage_is_prefix(void);
+void test_semanage_split_on_space(void);
+void test_semanage_split(void);
+void test_semanage_list(void);
+void test_semanage_str_count(void);
+void test_semanage_rtrim(void);
+void test_semanage_findval(void);
+void test_slurp_file_filter(void);
+
+char fname[] = {
+	'T', 'E', 'S', 'T', '_', 'T', 'E', 'M', 'P', '_', 'X', 'X', 'X', 'X',
+	'X', 'X'
+};
+int fd;
+FILE *fptr;
+
+int semanage_utilities_test_init(void)
+{
+	fd = mkstemp(fname);
+
+	if (fd < 0) {
+		perror("test_semanage_findval: ");
+		CU_FAIL_FATAL
+		    ("Error opening temporary file, test cannot start.");
+	}
+
+	fptr = fdopen(fd, "w+");
+	if (!fptr) {
+		perror("test_semanage_findval file: ");
+		CU_FAIL_FATAL("Error opening file stream, test cannot start.");
+	}
+
+	fprintf(fptr, "one\ntwo\nthree\nsigma=foo\n#boo\n#bar\n");
+
+	rewind(fptr);
+	return 0;
+}
+
+int semanage_utilities_test_cleanup(void)
+{
+	unlink(fname);
+	return 0;
+}
+
+int semanage_utilities_add_tests(CU_pSuite suite)
+{
+	if (NULL == CU_add_test(suite, "semanage_is_prefix",
+				test_semanage_is_prefix)) {
+		goto err;
+	}
+	if (NULL == CU_add_test(suite, "semanage_split_on_space",
+				test_semanage_split_on_space)) {
+		goto err;
+	}
+	if (NULL == CU_add_test(suite, "semanage_split", test_semanage_split)) {
+		goto err;
+	}
+	if (NULL == CU_add_test(suite, "semanage_list", test_semanage_list)) {
+		goto err;
+	}
+	if (NULL == CU_add_test(suite, "semanage_str_count",
+				test_semanage_str_count)) {
+		goto err;
+	}
+	if (NULL == CU_add_test(suite, "semanage_rtrim", test_semanage_rtrim)) {
+		goto err;
+	}
+	if (NULL == CU_add_test(suite, "semanage_findval",
+				test_semanage_findval)) {
+		goto err;
+	}
+	if (NULL == CU_add_test(suite, "slurp_file_filter",
+				test_slurp_file_filter)) {
+		goto err;
+	}
+	return 0;
+      err:
+	CU_cleanup_registry();
+	return CU_get_error();
+}
+
+void test_semanage_is_prefix(void)
+{
+	char *str = "some string";
+	char *pre = "some";
+	char *not_pre = "not this";
+
+	CU_ASSERT_TRUE(semanage_is_prefix(str, pre));
+	CU_ASSERT_TRUE(semanage_is_prefix(str, ""));
+	CU_ASSERT_TRUE(semanage_is_prefix(str, NULL));
+	CU_ASSERT_FALSE(semanage_is_prefix(str, not_pre));
+}
+
+void test_semanage_split_on_space(void)
+{
+	char *str = strdup("foo bar baz");
+	char *temp;
+
+	if (!str) {
+		CU_FAIL
+		    ("semanage_split_on_space: unable to perform test, no memory");
+	}
+	temp = semanage_split_on_space(str);
+	if (strncmp(temp, "bar", 3)) {
+		CU_FAIL("semanage_split_on_space: token did not match");
+	}
+	temp = semanage_split_on_space(temp);
+	if (strncmp(temp, "baz", 3)) {
+		CU_FAIL("semanage_split_on_space: token did not match");
+	}
+	temp = semanage_split_on_space(temp);
+	if (strcmp(temp, "")) {
+		CU_FAIL("semanage_split_on_space: token did not match");
+	}
+
+	free(str);
+}
+
+void test_semanage_split(void)
+{
+	char *str = strdup("foo1 foo2 foo:bar");
+	char *temp;
+
+	if (!str) {
+		CU_FAIL
+		    ("semanage_split_on_space: unable to perform test, no memory");
+		return;
+	}
+	temp = semanage_split(str, NULL);
+	CU_ASSERT_NSTRING_EQUAL(temp, "foo2", 4);
+	temp = semanage_split(temp, "");
+	CU_ASSERT_NSTRING_EQUAL(temp, "foo", 3);
+	temp = semanage_split(temp, ":");
+	CU_ASSERT_NSTRING_EQUAL(temp, "bar", 3);
+
+	free(str);
+}
+
+void test_semanage_list(void)
+{
+	semanage_list_t *list = NULL;
+	semanage_list_t *ptr = NULL;
+	char *temp = NULL;
+	int retval = 0;
+
+	CU_ASSERT_FALSE(semanage_list_push(&list, "foo"));
+	CU_ASSERT_PTR_NOT_NULL(list);
+	CU_ASSERT_FALSE(semanage_list_push(&list, "bar"));
+	CU_ASSERT_FALSE(semanage_list_push(&list, "gonk"));
+	CU_ASSERT_FALSE(semanage_list_push(&list, "zebra"));
+
+	for (ptr = list; ptr; ptr = ptr->next)
+		retval++;
+	CU_ASSERT_EQUAL(retval, 4);
+
+	temp = semanage_list_pop(&list);
+	CU_ASSERT_STRING_EQUAL(temp, "zebra");
+	CU_ASSERT_FALSE(semanage_list_push(&list, temp));
+	free(temp);
+	temp = NULL;
+
+	retval = 0;
+	for (ptr = list; ptr; ptr = ptr->next)
+		retval++;
+	CU_ASSERT_EQUAL(retval, 4);
+
+	retval = semanage_list_sort(&list);
+	if (retval) {
+		CU_FAIL
+		    ("semanage_list_sort: error unrelated to sort (memory?)");
+		goto past_sort;
+	}
+	CU_ASSERT_STRING_EQUAL(list->data, "bar");
+	CU_ASSERT_STRING_EQUAL(list->next->data, "foo");
+	CU_ASSERT_STRING_EQUAL(list->next->next->data, "gonk");
+	CU_ASSERT_STRING_EQUAL(list->next->next->next->data, "zebra");
+
+      past_sort:
+	ptr = semanage_list_find(list, "zebra");
+	CU_ASSERT_PTR_NOT_NULL(ptr);
+	ptr = semanage_list_find(list, "bogus");
+	CU_ASSERT_PTR_NULL(ptr);
+
+	semanage_list_destroy(&list);
+	CU_ASSERT_PTR_NULL(list);
+}
+
+void test_semanage_str_count(void)
+{
+	char *test_string = "abaababbaaaba";
+
+	CU_ASSERT_EQUAL(semanage_str_count(test_string, 'z'), 0);
+	CU_ASSERT_EQUAL(semanage_str_count(test_string, 'a'), 8);
+	CU_ASSERT_EQUAL(semanage_str_count(test_string, 'b'), 5);
+}
+
+void test_semanage_rtrim(void)
+{
+	char *str = strdup("/blah/foo/bar/baz/");
+
+	CU_ASSERT_PTR_NOT_NULL_FATAL(str);
+
+	semanage_rtrim(str, 'Q');
+	CU_ASSERT_STRING_EQUAL(str, "/blah/foo/bar/baz/");
+	semanage_rtrim(str, 'a');
+	CU_ASSERT_STRING_EQUAL(str, "/blah/foo/bar/b");
+	semanage_rtrim(str, '/');
+	CU_ASSERT_STRING_EQUAL(str, "/blah/foo/bar");
+}
+
+void test_semanage_findval(void)
+{
+	char *tok;
+	if (!fptr) {
+		CU_FAIL_FATAL("Temporary file was not created, aborting test.");
+	}
+	tok = semanage_findval(fname, "one", NULL);
+	CU_ASSERT_STRING_EQUAL(tok, "");
+	rewind(fptr);
+	tok = semanage_findval(fname, "one", "");
+	CU_ASSERT_STRING_EQUAL(tok, "");
+	free(tok);
+	rewind(fptr);
+	tok = semanage_findval(fname, "sigma", "=");
+	CU_ASSERT_STRING_EQUAL(tok, "foo");
+}
+
+int PREDICATE(const char *str)
+{
+	return semanage_is_prefix(str, "#");
+}
+
+void test_slurp_file_filter(void)
+{
+	semanage_list_t *data, *tmp;
+	int cnt = 0;
+
+	if (!fptr) {
+		CU_FAIL_FATAL("Temporary file was not created, aborting test.");
+	}
+	rewind(fptr);
+	data = semanage_slurp_file_filter(fptr, PREDICATE);
+	CU_ASSERT_PTR_NOT_NULL_FATAL(data);
+	for (tmp = data; tmp; tmp = tmp->next)
+		cnt++;
+	CU_ASSERT_EQUAL(cnt, 2);
+
+	semanage_list_destroy(&data);
+}
Index: selinux/libsemanage/tests/test_utilities.h
===================================================================
--- /dev/null
+++ selinux/libsemanage/tests/test_utilities.h
@@ -0,0 +1,5 @@
+#include <CUnit/Basic.h>
+
+int semanage_utilities_test_init(void);
+int semanage_utilities_test_cleanup(void);
+int semanage_utilities_add_tests(CU_pSuite suite);

-- 

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

[patch 4/4] libsemanage: remove genhomedircon python script

[tmiller]

remove legacy genhomedircon python script

Index: selinux/policycoreutils/scripts/genhomedircon
===================================================================
--- selinux.orig/policycoreutils/scripts/genhomedircon
+++ /dev/null
@@ -1,400 +0,0 @@
-#! /usr/bin/python -E
-# Copyright (C) 2004 Tresys Technology, LLC
-# see file 'COPYING' for use and warranty information
-#
-# genhomedircon - this script is used to generate file context
-# configuration entries for user home directories based on their
-# default prefixes and is run when building the policy. Specifically, we
-# replace HOME_ROOT, HOME_DIR, and ROLE macros in .fc files with
-# generic and user-specific values.
-#
-# Based off original script by Dan Walsh, <dwalsh@redhat.com>
-#
-# ASSUMPTIONS:
-#
-# The file CONTEXTDIR/files/homedir_template exists.  This file is used to
-# set up the home directory context for each real user.
-# 
-# If a user is not listed in CONTEXTDIR/seusers, he will default to user_u, prefix user
-#
-# "Real" users (as opposed to system users) are those whose UID is greater than
-#  or equal STARTING_UID (usually 500) and whose login is not a member of
-#  EXCLUDE_LOGINS.  Users who are explicitly defined in CONTEXTDIR/seusers
-#  are always "real" (including root, in the default configuration).
-#
-#  
-
-import sys, os, pwd, string, getopt, re
-from semanage import *;
-import selinux
-import gettext
-gettext.install('policycoreutils')
-
-def grep(file, var):
-	ret = ""
-	fd = open(file, 'r')
-
-	for i in  fd.readlines():
-	    if re.search(var, i, 0) != None:
-	        ret = i
-                break
-	fd.close()
-	return ret
-
-def findval(file, var, delim = ""):
-	val = ""
-	try:
-		fd = open(file, 'r')
-		for i in  fd.readlines():
-			if i.startswith(var) == 1:
-				if delim == "":
-					val = i.split()[1]
-				else:
-					val = i.split(delim)[1]
-				val = val.split("#")[0]
-				val = val.strip()
-		fd.close()
-	except:
-		val = ""
-	return val
-
-def getStartingUID():
-	starting_uid = sys.maxint
-	uid_min =  findval("/etc/login.defs", "UID_MIN")
-	if uid_min != "":
-		uid_min = uid_min.split("#")[0]
-		uid_min = uid_min.strip()
-		if int(uid_min) < starting_uid:
-			starting_uid = int(uid_min)
-
-	uid_min =  findval("/etc/libuser.conf", "LU_UIDNUMBER", "=")
-	if uid_min != "":
-		uid_min = uid_min.split("#")[0]
-		uid_min = uid_min.strip()
-		if int(uid_min) < starting_uid:
-			starting_uid = int(uid_min)
-
-	if starting_uid == sys.maxint:
-		starting_uid = 500
-	return starting_uid
-
-def getDefaultHomeDir():
-	ret = []
-	homedir = findval("/etc/default/useradd", "HOME", "=")
-	if homedir != "" and not homedir in ret:
-		ret.append(homedir)
-	
-	homedir = findval("/etc/libuser.conf", "LU_HOMEDIRECTORY", "=")
-	if homedir != "" and not homedir in ret:
-		ret.append(homedir)
-	
-	if ret == []:
-		ret.append("/home")
-
-	# Add /export/home if it exists
-	# Some customers use this for automounted homedirs
-	if os.path.exists("/export/home"):
-		ret.append("/export/home")
-
-	return ret
-
-def getSELinuxType(directory):
-	val = findval(directory+"/config", "SELINUXTYPE", "=")
-	if val != "":
-		return val
-	return "targeted"
-
-def usage(rc=0, error = ""):
-	if error != "":
-		sys.stderr.write("%s\n" % error)
-		rc = 1
-	sys.stderr.write("Usage: %s [ -d selinuxdir ] [-n | --nopasswd] [-t selinuxtype ]\n" % sys.argv[0])
-	sys.stderr.flush()
-	sys.exit(rc)
-
-def warning(warning = ""):
-	sys.stderr.write("%s\n" % warning)
-	sys.stderr.flush()
-	
-def errorExit(error):
-	sys.stderr.write("%s exiting for: " % sys.argv[0])
-	sys.stderr.write("%s\n" % error)
-	sys.stderr.flush()
-	sys.exit(1)
-
-class selinuxConfig:
-	def __init__(self, selinuxdir = "/etc/selinux", type = "targeted", usepwd = 1):
-		self.semanageHandle = semanage_handle_create()
-		self.semanaged = semanage_is_managed(self.semanageHandle)
-		if self.semanaged:
-			rc = semanage_connect(self.semanageHandle)
-			if rc:
-				errorExit("Unable to connect to semanage")
-			(status, self.ulist) = semanage_user_list(self.semanageHandle)
-		self.type = type
-		self.selinuxdir = selinuxdir +"/"
-		self.contextdir = "/contexts"
-		self.filecontextdir = self.contextdir+"/files"
-		self.usepwd = usepwd
-		self.default_user = "user_u"
-		self.default_prefix = "user"
-		self.users = self.getUsers()
-
-	def getFileContextDir(self):
-		return self.selinuxdir+self.type+self.filecontextdir
-
-	def getFileContextFile(self):
-		return self.getFileContextDir()+"/file_contexts"
-	
-	def getContextDir(self):
-		return self.selinuxdir+self.type+self.contextdir
-
-	def getHomeDirTemplate(self):
-		return self.getFileContextDir()+"/homedir_template"
-
-	def getHomeRootContext(self, homedir):
-		ret = ""
-		fd = open(self.getHomeDirTemplate(), 'r')
-
-		for i in  fd.readlines():
-			if i.find("HOME_ROOT") == 0:
-				i = i.replace("HOME_ROOT", homedir)
-				ret += i
-		fd.close()
-		if ret == "":
-			errorExit("No Home Root Context Found")
-		return ret
-
-	def heading(self):
-		ret = "\n#\n#\n# User-specific file contexts, generated via %s\n" % sys.argv[0]
-		if self.semanaged:
-			ret += "# use semanage command to manage system users in order to change the file_context\n#\n#\n"
-		else:
-			ret += "# edit %s to change file_context\n#\n#\n" % (self.selinuxdir+self.type+"/seusers")
-		return ret
-
-	def get_default_prefix(self, name):
-		for user in self.ulist:
-			if semanage_user_get_name(user) == name:
-				return semanage_user_get_prefix(user)
-		return name
-
-	def get_old_prefix(self, user):
-		rc = grep(self.selinuxdir+self.type+"/users/system.users", "^user %s" % user)
-		if rc == "":					    
-			rc = grep(self.selinuxdir+self.type+"/users/local.users", "^user %s" % user)
-		if rc != "":
-			user = rc.split()
-			prefix  =  user[3]
-			if prefix == "{":
-				prefix = user[4]
-		if len(prefix) > 2 and (prefix[-2:] == "_r" or prefix[-2:] == "_u"):
-			prefix = prefix[:-2]
-		return prefix
-		
-	def adduser(self, udict, user, seuser, prefix):
-		if seuser == self.default_user or user == "__default__" or user == "system_u":
-			return
-		# !!! chooses first prefix in the list to use in the file context !!!
-		try:
-			home = pwd.getpwnam(user)[5]
-			if home == "/":
-				# Probably install so hard code to /root
-				if user == "root":
-					home = "/root"
-				else:
-					return
-		except KeyError:
-			if user == "root":
-				home = "/root"
-			else:
-				sys.stderr.write("The user \"%s\" is not present in the passwd file, skipping...\n" % user)
-				return
-		prefs = {}
-		prefs["seuser"] = seuser
-		prefs["prefix"] = prefix
-		prefs["home"] = home
-		udict[user] = prefs
-			
-	def setDefaultUser(self, user, prefix):
-		self.default_user = user
-		self.default_prefix = prefix
-		
-	def getUsers(self):
-		udict = {}
-		if self.semanaged:
-			(status, list) = semanage_seuser_list(self.semanageHandle)
-			for seuser in list:
-				user = []
-				seusername = semanage_seuser_get_sename(seuser)
-				prefix = self.get_default_prefix(seusername)
-				if semanage_seuser_get_name(seuser) == "__default__":
-					self.setDefaultUser(seusername, prefix)
-
-				self.adduser(udict, semanage_seuser_get_name(seuser), seusername, prefix)
-				
-		else:
-			try:
-				fd = open(self.selinuxdir+self.type+"/seusers")
-				for u in  fd.readlines():
-					u = u.strip()
-					if len(u) == 0 or u[0] == "#":
-						continue
-					user = u.split(":")
-					if len(user) < 2:
-						continue
-					
-					prefix = self.get_old_prefix(user[1])
-					self.adduser(udict, user[0], user[1], prefix)
-				fd.close()
-			except IOError, error:
-				# Must be install so force add of root
-				self.adduser(udict, "root", "root", "root")
-
-		return udict
-
-	def getHomeDirContext(self, user, seuser, home, prefix):
-		ret = "\n\n#\n# Home Context for user %s\n#\n\n" % user
-		fd = open(self.getHomeDirTemplate(), 'r')
-		for i in  fd.readlines():
-			if i.startswith("HOME_DIR") == 1:
-				i = i.replace("HOME_DIR", home)
-				i = i.replace("ROLE", prefix)
-				i = i.replace("system_u", seuser)
-				# Validate if the generated context exists.  Some user types may not exist
-				scon = i.split()[-1]
-				if selinux.is_selinux_enabled() < 1 or selinux.security_check_context(scon) == 0:
-					ret = ret+i
-		fd.close()
-		return ret
-
-	def getUserContext(self, user, sel_user, prefix):
-		ret = ""
-		fd = open(self.getHomeDirTemplate(), 'r')
-		for i in  fd.readlines():
-			if i.find("USER") == 1:
-				i = i.replace("USER", user)
-				i = i.replace("ROLE", prefix)
-				i = i.replace("system_u", sel_user)
-				ret = ret+i
-		fd.close()
-		return ret
-
-	def genHomeDirContext(self):
-		ret = ""
-		# Fill in HOME and prefix for users that are defined
-		for u in self.users.keys():
-			ret += self.getHomeDirContext (u, self.users[u]["seuser"], self.users[u]["home"], self.users[u]["prefix"])
-			ret += self.getUserContext (u, self.users[u]["seuser"], self.users[u]["prefix"])
-		return ret+"\n"
-
-	def checkExists(self, home):
-		fd = open(self.getFileContextFile())
-		for i in  fd.readlines():
-                    if len(i) == 0:
-			    continue
-		    try:
-			    regex = i.split()[0]
-			    #match a trailing .+
-			    regex = re.sub("\.+$", "", regex)
-			    regex = re.sub("\.\*$", "", regex)
-			    #strip a (/.*)? which matches anything trailing to a /*$ which matches trailing /'s
-			    
-			    regex = re.sub("\(\/\.\*\)\?", "", regex)
-			    regex = regex + "/*$"
-			    if re.search(regex,home, 0):
-				    return 1
-		    except:
-			    continue
-		return 0
-
-	def getHomeDirs(self):
-		homedirs = getDefaultHomeDir()
-		starting_uid = getStartingUID()
-		if self.usepwd == 0:
-			return homedirs
-		ulist = pwd.getpwall()
-		for u in ulist:
-			if u[2] >= starting_uid and \
-					u[6] in VALID_SHELLS and \
-					u[5] != "/" and \
-					string.count(u[5], "/") > 1:
-				homedir = u[5][:string.rfind(u[5], "/")]
-				if not homedir in homedirs:
-					if self.checkExists(homedir) == 1:
-						warning("%s homedir %s or its parent directory conflicts with a\ndefined context in %s,\n%s will not create a new context. This usually indicates an incorrectly defined system account.  If it is a system account please make sure its login shell is /sbin/nologin." % (u[0], u[5], self.getFileContextFile(), sys.argv[0]))
-					else:
-						homedirs.append(homedir)
-
-		homedirs.sort()
-		return homedirs
- 
-	def genoutput(self):
-		ret = self.heading()
-		for h in self.getHomeDirs():
-			ret += self.getHomeDirContext (self.default_user, self.default_user, h+'/[^/]*', self.default_prefix)
-			ret += self.getHomeRootContext(h)
-		ret += self.getUserContext(".*", self.default_user, self.default_prefix) + "\n"
-		ret += self.genHomeDirContext()
-		return ret
-
-	def printout(self):
-		print self.genoutput()
-
-	def write(self):
-		fd = open(self.getFileContextDir()+"/file_contexts.homedirs", "w")
-		fd.write(self.genoutput())
-		fd.close()
-
-if os.getuid() > 0 or os.geteuid() > 0:
-	print _("You must be root to run %s.") % sys.argv[0]
-	sys.exit(1)
-
-try:
-	fd = open("/etc/shells", 'r')
-	VALID_SHELLS = fd.read().split("\n")
-	fd.close()
-	if "/sbin/nologin" in VALID_SHELLS:
-		VALID_SHELLS.remove("/sbin/nologin")
-	if "" in VALID_SHELLS:
-		VALID_SHELLS.remove("")
-except:
-	VALID_SHELLS = ['/bin/sh', '/bin/bash', '/bin/ash', '/bin/bsh', '/bin/ksh', '/usr/bin/ksh', '/usr/bin/pdksh', '/bin/tcsh', '/bin/csh', '/bin/zsh']
-
-#
-# This script will generate home dir file context
-# based off the homedir_template file, entries in the password file, and
-#
-try:
-	usepwd = 1
-	directory = "/etc/selinux"
-	type = None
-	gopts, cmds = getopt.getopt(sys.argv[1:], 'hnd:t:', ['help',
-						'type=',
-						'nopasswd',
-						'dir='])
-	for o,a in gopts:
-		if o == '--type' or o == "-t":
-			type = a
-		if o == '--nopasswd'  or o == "-n":
-			usepwd = 0
-		if o == '--dir'  or o == "-d":
-			directory = a
-		if o == '--help'  or o == "-h":
-			usage()
-except getopt.error, error:
-	errorExit(_("Options Error %s ") % error)
-
-if type == None:
-	type = getSELinuxType(directory)
-
-if len(cmds) != 0:
-	usage(1)
-
-selconf = selinuxConfig(directory, type, usepwd)
-try:
-	selconf.write()
-except IOError, error:
-	sys.stderr.write("%s: %s\n" % ( sys.argv[0], error ))
-	sys.exit(1)
-
Index: selinux/policycoreutils/scripts/genhomedircon.8
===================================================================
--- selinux.orig/policycoreutils/scripts/genhomedircon.8
+++ /dev/null
@@ -1,82 +0,0 @@
-.\" Hey, Emacs! This is an -*- nroff -*- source file.
-.\" Copyright (c) 2005 Manoj Srivastava <srivasta@debian.org>
-.\"
-.\" This is free documentation; you can redistribute it and/or
-.\" modify it under the terms of the GNU General Public License as
-.\" published by the Free Software Foundation; either version 2 of
-.\" the License, or (at your option) any later version.
-.\"
-.\" The GNU General Public License's references to "object code"
-.\" and "executables" are to be interpreted as the output of any
-.\" document formatting or typesetting system, including
-.\" intermediate and printed output.
-.\"
-.\" This manual is distributed in the hope that it will be useful,
-.\" but WITHOUT ANY WARRANTY; without even the implied warranty of
-.\" MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
-.\" GNU General Public License for more details.
-.\"
-.\" You should have received a copy of the GNU General Public
-.\" License along with this manual; if not, write to the Free
-.\" Software Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139,
-.\" USA.
-.\"
-.\"
-.TH GENHOMEDIRCON "8" "January 2005" "Security Enhanced Linux" ""
-.SH NAME
-genhomedircon \- generate SELinux file context configuration entries for user home directories 
-.SH SYNOPSIS
-.B genhomedircon [ -d selinuxdir ] [-n | --nopasswd] [-t selinuxtype ] [-h]
-
-.SH OPTIONS
-.TP
-.B "\-h"
-Print a short usage message
-.TP
-.B "\-d selinuxdir (\-\-directory)"
-Directory where selinux files are installed defaults to /etc/selinux
-.TP
-.B 
-\-n \-\-nopasswd
-Indicates to the utility not to read homedirectories out of the password database.  
-.TP
-\-t selinuxtype (\-\-type)
-Indicates the selinux type of this install.  Defaults to "targeted".
-.SH DESCRIPTION
-.PP
-This utility is used to generate file context configuration entries for 
-user home directories based on their 
-.B prefix 
-entry in the the 
-.B semanage user record.  
-genhomedircon is run when building 
-the policy. It is also run automaticaly when ever the 
-.B semanage 
-utility modifies 
-.B user
-or
-.B login
-records.
-Specifically, we replace HOME_ROOT, HOME_DIR, and ROLE macros in the 
-.I /etc/selinux/<<SELINUXTYPE>>/contexts/files/homedir_template 
-file with generic and user-specific values.  HOME_ROOT and HOME_DIR is replaced with each distinct location where login users homedirectories are located.  Defaults to /home. ROLE is replaced based on the prefix entry in the 
-.B user
-record.
-.PP 
-genhomedircon searches through all password entires for all "login" user home directories, (as opposed
-to system users).  Login users are those whose UID is greater than or equal 
-.I STARTING_UID
-(default 500) and whose login shell is not "/sbin/nologin", or
-"/bin/false". 
-.PP 
-.SH AUTHOR
-This manual page was originally written by 
-.I Manoj Srivastava <srivasta@debian.org>,
-for the Debian GNU/Linux system, based on the comments and the code
-in the utility, and then updated by Dan Walsh of Red Hat. The 
-.B genhomedircon
-utility was originally written by 
-.I Dan Walsh of Red Hat 
-with some modifications by 
-.I Tresys Technology, LLC.
-
Index: selinux/policycoreutils/scripts/Makefile
===================================================================
--- selinux.orig/policycoreutils/scripts/Makefile
+++ selinux/policycoreutils/scripts/Makefile
@@ -5,18 +5,14 @@ SBINDIR ?= $(PREFIX)/sbin
 MANDIR ?= $(PREFIX)/share/man
 LOCALEDIR ?= /usr/share/locale
 
-TARGETS=genhomedircon 
-
-all: $(TARGETS) fixfiles
+all: fixfiles
 
 install: all
 	-mkdir -p $(BINDIR)
-	install -m 755 $(TARGETS) $(SBINDIR)
 	install -m 755 chcat $(BINDIR)
 	install -m 755 fixfiles $(DESTDIR)/sbin
 	-mkdir -p $(MANDIR)/man8
 	install -m 644 fixfiles.8 $(MANDIR)/man8/
-	install -m 644 genhomedircon.8 $(MANDIR)/man8/
 	install -m 644 chcat.8 $(MANDIR)/man8/
 
 clean:

-- 

--
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: [patch 0/4] libsemanage: genhomedircon replacement

[Todd C. Miller]

Stephen Smalley wrote:
> BTW, the C code shouldn't be using getpwnam or getpwent - it should be
> using the _r versions of those functions since it is a library.

Below is a diff to use the _r versions.  I sent this out some time ago
but apparently it didn't make it to the list.

 - todd

 genhomedircon.c |   32 +++++++++++++++++++++++++++-----
 1 file changed, 27 insertions(+), 5 deletions(-)

Index: libsemanage/src/genhomedircon.c
===================================================================
--- libsemanage/src/genhomedircon.c	(revision 2549)
+++ libsemanage/src/genhomedircon.c	(working copy)
@@ -41,6 +41,7 @@
 #include <fcntl.h>
 #include <pwd.h>
 #include <errno.h>
+#include <unistd.h>
 
 /* paths used in get_home_dirs() */
 #define PATH_ETC_USERADD "/etc/default/useradd"
@@ -145,11 +146,13 @@
 {
 	semanage_list_t *homedir_list = NULL;
 	semanage_list_t *shells = NULL;
+	char *rbuf = NULL;
 	char *path = NULL;
+	long rbuflen;
 	size_t minuid = 0;
 	size_t minuid_set = 0;
 	size_t temp;
-	struct passwd *pwbuf;
+	struct passwd pwstorage, *pwbuf;
 	struct stat buf;
 
 	shells = get_shell_list();
@@ -215,8 +218,14 @@
 		minuid_set = 1;
 	}
 
+	rbuflen = sysconf(_SC_GETPW_R_SIZE_MAX);
+	if (rbuflen <= 0)
+		goto fail;
+	rbuf = malloc(rbuflen);
+	if (rbuf == NULL)
+		goto fail;
 	setpwent();
-	for (errno = 0; (pwbuf = getpwent()); errno = 0) {
+	for (errno = 0; getpwent_r(&pwstorage, rbuf, rbuflen, &pwbuf) == 0; errno = 0) {
 		if (pwbuf->pw_uid < minuid)
 			continue;
 		if (!semanage_list_find(shells, pwbuf->pw_shell))
@@ -244,6 +253,7 @@
 		     "Returning list so far.");
 	}
 	endpwent();
+	free(rbuf);
 	semanage_list_destroy(&shells);
 	if (semanage_list_sort(&homedir_list))
 		goto fail;
@@ -251,6 +261,8 @@
 	return homedir_list;
 
       fail:
+	endpwent();
+	free(rbuf);
 	semanage_list_destroy(&homedir_list);
 	semanage_list_destroy(&shells);
 	return NULL;
@@ -496,8 +508,10 @@
 	const char *name = NULL;
 	const char *seuname = NULL;
 	const char *prefix = NULL;
-	struct passwd *pwent = NULL;
+	struct passwd pwstorage, *pwent = NULL;
 	unsigned int i;
+	long rbuflen;
+	char *rbuf = NULL;
 	int retval;
 
 	*errors = 0;
@@ -514,6 +528,14 @@
 	qsort(user_list, nusers, sizeof(semanage_user_t *),
 	      (int (*)(const void *, const void *))&user_sort_func);
 
+	/* Allocate space for the getpwnam_r buffer */
+	rbuflen = sysconf(_SC_GETPW_R_SIZE_MAX);
+	if (rbuflen <= 0)
+		goto cleanup;
+	rbuf = malloc(rbuflen);
+	if (rbuf == NULL)
+		goto cleanup;
+
 	for (i = 0; i < nseusers; i++) {
 		name = semanage_seuser_get_name(seuser_list[i]);
 		seuname = semanage_seuser_get_sename(seuser_list[i]);
@@ -536,8 +558,7 @@
 		}
 
 		errno = 0;
-		pwent = getpwnam(name);
-		if (!pwent) {
+		if (getpwnam_r(name, &pwstorage, rbuf, rbuflen, &pwent) != 0) {
 			if (errno != 0) {
 				*errors = STATUS_ERR;
 				goto cleanup;
@@ -561,6 +582,7 @@
 	}
 
       cleanup:
+	free(rbuf);
 	if (*errors) {
 		for (; head; pop_user_entry(&head)) {
 			/* the pop function takes care of all the cleanup

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