All of lore.kernel.org
 help / color / mirror / Atom feed
From: Daniel J Walsh <dwalsh@redhat.com>
To: Karl MacMillan <kmacmillan@mentalrootkit.com>
Cc: Stephen Smalley <sds@tycho.nsa.gov>,
	Joshua Brindle <jbrindle@tresys.com>,
	Todd Miller <tmiller@tresys.com>,
	selinux@tycho.nsa.gov
Subject: Re: [patch 0/4] libsemanage: genhomedircon replacement
Date: Thu, 06 Sep 2007 16:33:39 -0400	[thread overview]
Message-ID: <46E06423.6030707@redhat.com> (raw)
In-Reply-To: <1189104986.5251.15.camel@localhost.localdomain>

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

  reply	other threads:[~2007-09-06 20:33 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-08-15 20:44 [patch 0/4] libsemanage: genhomedircon replacement tmiller
2007-08-15 15:10 ` Karl MacMillan
2007-08-15 15:29   ` Joshua Brindle
2007-08-15 15:47     ` Karl MacMillan
2007-08-15 15:57       ` Joshua Brindle
2007-08-15 17:22         ` Stephen Smalley
2007-08-15 17:37           ` Joshua Brindle
2007-08-15 19:21             ` Karl MacMillan
2007-08-15 19:16           ` Karl MacMillan
2007-08-15 19:56             ` Stephen Smalley
2007-08-15 20:17               ` Karl MacMillan
2007-08-15 20:31                 ` Stephen Smalley
2007-08-15 20:41                   ` Karl MacMillan
2007-08-15 20:47                     ` Joshua Brindle
2007-08-15 21:09                       ` Karl MacMillan
2007-08-15 21:12                         ` Joshua Brindle
2007-08-15 21:40                           ` Joshua Brindle
2007-08-17 13:33                           ` Karl MacMillan
2007-08-16 16:01                         ` Stephen Smalley
2007-08-17 13:31                           ` Karl MacMillan
2007-08-17 18:20                             ` Joshua Brindle
2007-08-27 17:50                           ` Daniel J Walsh
2007-08-28 14:21                             ` Joshua Brindle
2007-08-28 14:30                               ` Stephen Smalley
2007-08-28 14:46                               ` Karl MacMillan
2007-08-28 16:37                                 ` Daniel J Walsh
2007-09-06 18:51                                   ` Stephen Smalley
2007-09-06 18:56                                     ` Karl MacMillan
2007-09-06 20:33                                       ` Daniel J Walsh [this message]
2007-09-07 13:48                                         ` Karl MacMillan
2007-08-15 20:44                   ` Joshua Brindle
2007-08-15 20:44 ` [patch 1/4] libsemanage: genhomedircon initial cleanup tmiller
2007-08-15 20:44 ` [patch 2/4] libsemanage: genhomedircon replacement tmiller
2007-08-16 19:31   ` Stephen Smalley
2007-08-15 20:44 ` [patch 3/4] libsemanage: test functions tmiller
2007-08-15 20:44 ` [patch 4/4] libsemanage: remove genhomedircon python script tmiller
  -- strict thread matches above, loose matches on Subject: below --
2007-09-06 19:16 [patch 0/4] libsemanage: genhomedircon replacement Todd C. Miller

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=46E06423.6030707@redhat.com \
    --to=dwalsh@redhat.com \
    --cc=jbrindle@tresys.com \
    --cc=kmacmillan@mentalrootkit.com \
    --cc=sds@tycho.nsa.gov \
    --cc=selinux@tycho.nsa.gov \
    --cc=tmiller@tresys.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.