User home directory creation with useradd (rhbz#217441)

User home directory creation with useradd (rhbz#217441)

[James Antill]

[-- Attachment #1: Type: text/plain, Size: 930 bytes --]


 As some of you know, there's an open BZ about the fact that in a
strict/MLS environment useradd doesn't create the user's homedir with
the correct context[1].
 The problem is that matchpathcon() needs semanage to have run, so we
know what SELinux user the unix user is associated with, but that runs
separately and after useradd. The four obvious solutions are:

1. Have an option for useradd to call semanage to add the selinux user,
and then do the restorecon.

2. Have semanage do the equivalent of a restorecon when doing an
add/modify (or just add) of SELinux user information.

3. Have some kind of wrapper that does:
	i. useradd
	ii. semanage
	iii. restorecon

4. Document that you need to call the list of programs in #3.

 Does anyone have comments on which of the above they like/hate?


[1] http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=217441

-- 
James Antill <jantill@redhat.com>

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: User home directory creation with useradd (rhbz#217441)

[Karl MacMillan]

James Antill wrote:
>  As some of you know, there's an open BZ about the fact that in a
> strict/MLS environment useradd doesn't create the user's homedir with
> the correct context[1].
>  The problem is that matchpathcon() needs semanage to have run, so we
> know what SELinux user the unix user is associated with, but that runs
> separately and after useradd. The four obvious solutions are:
> 
> 1. Have an option for useradd to call semanage to add the selinux user,
> and then do the restorecon.
> 

I think this is the best option, though there needs to be additional 
flags to useradd added to allow the setting or roles.

> 2. Have semanage do the equivalent of a restorecon when doing an
> add/modify (or just add) of SELinux user information.
> 

I think this is needed in addition to one for changes to users. Should 
be optional (but perhaps on by default) since the operating is 
potentially expensive.

> 3. Have some kind of wrapper that does:
> 	i. useradd
> 	ii. semanage
> 	iii. restorecon
> 

Setools used to include something like this - didn't get much use that I 
am aware of because no one knew it was there. I would prefer patching 
the default tools.

> 4. Document that you need to call the list of programs in #3.
> 

Nobody reads documentation - this isn't viable.

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: User home directory creation with useradd (rhbz#217441)

[David O'Brien]

On Saturday 02 December 2006 06:22, Karl MacMillan wrote:
> James Antill wrote:
> >  As some of you know, there's an open BZ about the fact that in a
> > strict/MLS environment useradd doesn't create the user's homedir with
> > the correct context[1].
> >  The problem is that matchpathcon() needs semanage to have run, so we
> > know what SELinux user the unix user is associated with, but that runs
> > separately and after useradd. The four obvious solutions are:
> >
> > 1. Have an option for useradd to call semanage to add the selinux user,
> > and then do the restorecon.
>
> I think this is the best option, though there needs to be additional
> flags to useradd added to allow the setting or roles.
>
> > 2. Have semanage do the equivalent of a restorecon when doing an
> > add/modify (or just add) of SELinux user information.
>
> I think this is needed in addition to one for changes to users. Should
> be optional (but perhaps on by default) since the operating is
> potentially expensive.
>
> > 3. Have some kind of wrapper that does:
> >  i. useradd
> >  ii. semanage
> >  iii. restorecon
>
> Setools used to include something like this - didn't get much use that I
> am aware of because no one knew it was there. I would prefer patching
> the default tools.
>
> > 4. Document that you need to call the list of programs in #3.
>
> Nobody reads documentation - this isn't viable.  <--------  !!

Karl... be nice. Tech writers are sensitive beings  ;-)


-- 
David

--
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: User home directory creation with useradd (rhbz#217441)

[Karl MacMillan]

David O'Brien wrote:
> On Saturday 02 December 2006 06:22, Karl MacMillan wrote:
>>> 4. Document that you need to call the list of programs in #3.
>> Nobody reads documentation - this isn't viable.  <--------  !!
> 
> Karl... be nice. Tech writers are sensitive beings  ;-)
> 

Sorry! What I really should have said is, people don't normally find 
features through documentation. Rather, they resort to docs once what 
they have found doesn't work correctly. So in this case, if the features 
aren't part of useradd it is unlikely they will find semanage or any 
other SELinux feature.

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: User home directory creation with useradd (rhbz#217441)

[David O'Brien]

On Monday 04 December 2006 23:49, Karl MacMillan wrote:
> David O'Brien wrote:
> > On Saturday 02 December 2006 06:22, Karl MacMillan wrote:
> >>> 4. Document that you need to call the list of programs in #3.
> >>
> >> Nobody reads documentation - this isn't viable.  <--------  !!
> >
> > Karl... be nice. Tech writers are sensitive beings  ;-)
>
> Sorry! What I really should have said is, people don't normally find
> features through documentation. Rather, they resort to docs once what
> they have found doesn't work correctly. So in this case, if the features
> aren't part of useradd it is unlikely they will find semanage or any
> other SELinux feature.
>
> Karl

/me re-emerges from shell...  :-)

I'm pretty familiar with it. "When all else fails, read the doc."

--
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: User home directory creation with useradd (rhbz#217441)

[Linda Knippers]

James Antill wrote:
>  As some of you know, there's an open BZ about the fact that in a
> strict/MLS environment useradd doesn't create the user's homedir with
> the correct context[1].
>  The problem is that matchpathcon() needs semanage to have run, so we
> know what SELinux user the unix user is associated with, but that runs
> separately and after useradd. The four obvious solutions are:
> 
> 1. Have an option for useradd to call semanage to add the selinux user,
> and then do the restorecon.

I think useradd should be able to either create the selinux user or map the
linux user to an existing selinux user.  Right now you can't create an
selinux user without a linux login but I think I ought to be able to create
the selinux users separate and them map one or more linux login to each one,
or have useradd create a unique linux user for me if I choose.  And if I
don't choose, the linux user should end up with the correct home directory
based on the default selinux user.
> 
> 2. Have semanage do the equivalent of a restorecon when doing an
> add/modify (or just add) of SELinux user information.

If the semanage is done after the useradd (could be weeks after), the
user could have files that live outside the home directory (I think
Dan pointed this out to me) so what files and directories would you
run restorecon on?
> 
> 3. Have some kind of wrapper that does:
> 	i. useradd
> 	ii. semanage
> 	iii. restorecon

I don't like the wrapper idea because if we can do it in a wrapper,
we can do it in useradd.
> 
> 4. Document that you need to call the list of programs in #3.

I think we need to document that anytime semanage is used one
might need to run restorecon.  There's nothing in the semanage
manpage about that, for example.
> 
>  Does anyone have comments on which of the above they like/hate?
> 
> 
> [1] http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=217441
> 

-- ljk

--
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: User home directory creation with useradd (rhbz#217441)

[Russell Coker]

On Saturday 02 December 2006 07:47, Linda Knippers <linda.knippers@hp.com> 
wrote:
> > 1. Have an option for useradd to call semanage to add the selinux user,
> > and then do the restorecon.
>
> I think useradd should be able to either create the selinux user or map the
> linux user to an existing selinux user.  Right now you can't create an
> selinux user without a linux login

I think that this is a bug.  You should be able to create SE Linux users 
without Linux logins, if only for the case of a NIS/LDAP server being down at 
SE Linux user creation time.

> but I think I ought to be able to create 
> the selinux users separate and them map one or more linux login to each
> one, or have useradd create a unique linux user for me if I choose.  And if
> I don't choose, the linux user should end up with the correct home
> directory based on the default selinux user.

I think that part of the solution is to have semanage call useradd.

> > 2. Have semanage do the equivalent of a restorecon when doing an
> > add/modify (or just add) of SELinux user information.
>
> If the semanage is done after the useradd (could be weeks after), the
> user could have files that live outside the home directory (I think
> Dan pointed this out to me) so what files and directories would you
> run restorecon on?

Also for a MLS environment you can't just relabel the files unless the new 
sensitivity label dominates the old.  For a strict policy system it's 
generally acceptable for relabel the files, but for MLS that won't work.

> > 3. Have some kind of wrapper that does:
> > 	i. useradd
> > 	ii. semanage
> > 	iii. restorecon
>
> I don't like the wrapper idea because if we can do it in a wrapper,
> we can do it in useradd.

Or semanage, or do it in both and give the sys-admin a choice.

-- 
russell@coker.com.au
http://etbe.blogspot.com/          My Blog

http://www.coker.com.au/sponsorship.html Sponsoring Free Software development

--
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: User home directory creation with useradd (rhbz#217441)

[Joshua Brindle]

Russell Coker wrote:
> On Saturday 02 December 2006 07:47, Linda Knippers <linda.knippers@hp.com> 
> wrote:
>   
>>> 1. Have an option for useradd to call semanage to add the selinux user,
>>> and then do the restorecon.
>>>       
>> I think useradd should be able to either create the selinux user or map the
>> linux user to an existing selinux user.  Right now you can't create an
>> selinux user without a linux login
>>     
>
> I think that this is a bug.  You should be able to create SE Linux users 
> without Linux logins, if only for the case of a NIS/LDAP server being down at 
> SE Linux user creation time.
>
>   
You can create them all you want, you just can't log in with a user that 
has a matching selinux user without a login mapping the linux user to 
the selinux user, this is by design, we don't want the implicit mapping.

>> but I think I ought to be able to create 
>> the selinux users separate and them map one or more linux login to each
>> one, or have useradd create a unique linux user for me if I choose.  And if
>> I don't choose, the linux user should end up with the correct home
>> directory based on the default selinux user.
>>     
>
> I think that part of the solution is to have semanage call useradd.
>
>   
no. semanage is managing selinux and selinux resources, not logins, not 
system resources.
>>> 2. Have semanage do the equivalent of a restorecon when doing an
>>> add/modify (or just add) of SELinux user information.
>>>       
>> If the semanage is done after the useradd (could be weeks after), the
>> user could have files that live outside the home directory (I think
>> Dan pointed this out to me) so what files and directories would you
>> run restorecon on?
>>     
>
> Also for a MLS environment you can't just relabel the files unless the new 
> sensitivity label dominates the old.  For a strict policy system it's 
> generally acceptable for relabel the files, but for MLS that won't work.
>
>   
you can if the thing relabeling is mls privileged, the useradd program 
or whatever labels the home directory would have that privilege
>>> 3. Have some kind of wrapper that does:
>>> 	i. useradd
>>> 	ii. semanage
>>> 	iii. restorecon
>>>       
>> I don't like the wrapper idea because if we can do it in a wrapper,
>> we can do it in useradd.
>>     
>
> Or semanage, or do it in both and give the sys-admin a choice.
>   
semanage does not manage system resources.



--
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: User home directory creation with useradd (rhbz#217441)

[Russell Coker]

On Saturday 02 December 2006 14:20, Joshua Brindle <jbrindle@tresys.com> 
wrote:
> > I think that this is a bug.  You should be able to create SE Linux users
> > without Linux logins, if only for the case of a NIS/LDAP server being
> > down at SE Linux user creation time.
>
> You can create them all you want, you just can't log in with a user that
> has a matching selinux user without a login mapping the linux user to
> the selinux user, this is by design, we don't want the implicit mapping.

Note that I am talking about Linux accounts (entries in /etc/passwd) when I 
say "Linux logins".

> >> but I think I ought to be able to create
> >> the selinux users separate and them map one or more linux login to each
> >> one, or have useradd create a unique linux user for me if I choose.  And
> >> if I don't choose, the linux user should end up with the correct home
> >> directory based on the default selinux user.
> >
> > I think that part of the solution is to have semanage call useradd.
>
> no. semanage is managing selinux and selinux resources, not logins, not
> system resources.

The sys-admin is wanting to create an entry for a user who can login.  They 
don't want to think about creating a home directory, creating a group, a 
user, a home directory, a SE Linux user, and a SE Linux login mapping entry.

> >>> 2. Have semanage do the equivalent of a restorecon when doing an
> >>> add/modify (or just add) of SELinux user information.
> >>
> >> If the semanage is done after the useradd (could be weeks after), the
> >> user could have files that live outside the home directory (I think
> >> Dan pointed this out to me) so what files and directories would you
> >> run restorecon on?
> >
> > Also for a MLS environment you can't just relabel the files unless the
> > new sensitivity label dominates the old.  For a strict policy system it's
> > generally acceptable for relabel the files, but for MLS that won't work.
>
> you can if the thing relabeling is mls privileged, the useradd program
> or whatever labels the home directory would have that privilege

Sure, you can break whatever security goals you might have if your process is 
sufficiently privileged.  You can turn off SE Linux too if that's what you 
desire.

But if your aim is that s15 data never gets relabeled to s0 then you are 
limited in what you can do if you want to achieve your aim.

-- 
russell@coker.com.au
http://etbe.blogspot.com/          My Blog

http://www.coker.com.au/sponsorship.html Sponsoring Free Software development

--
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: User home directory creation with useradd (rhbz#217441)

[Joshua Brindle]

> From: Russell Coker [mailto:russell@coker.com.au] 
> 
> On Saturday 02 December 2006 14:20, Joshua Brindle 
> <jbrindle@tresys.com>
> wrote:
> > > I think that this is a bug.  You should be able to create 
> SE Linux 
> > > users without Linux logins, if only for the case of a NIS/LDAP 
> > > server being down at SE Linux user creation time.
> >
> > You can create them all you want, you just can't log in with a user 
> > that has a matching selinux user without a login mapping the linux 
> > user to the selinux user, this is by design, we don't want 
> the implicit mapping.
> 
> Note that I am talking about Linux accounts (entries in 
> /etc/passwd) when I say "Linux logins".
> 

Yes, I know. You said "You should be able to create SE Linux users
without Linux logins", I said you can.

> > >> but I think I ought to be able to create the selinux 
> users separate 
> > >> and them map one or more linux login to each one, or 
> have useradd 
> > >> create a unique linux user for me if I choose.  And if I don't 
> > >> choose, the linux user should end up with the correct home 
> > >> directory based on the default selinux user.
> > >
> > > I think that part of the solution is to have semanage 
> call useradd.
> >
> > no. semanage is managing selinux and selinux resources, not logins, 
> > not system resources.
> 
> The sys-admin is wanting to create an entry for a user who 
> can login.  They don't want to think about creating a home 
> directory, creating a group, a user, a home directory, a SE 
> Linux user, and a SE Linux login mapping entry.
> 

Doesn't matter, semanage doesn't need any more feature creep than it has
right now.

> > >>> 2. Have semanage do the equivalent of a restorecon when 
> doing an 
> > >>> add/modify (or just add) of SELinux user information.
> > >>
> > >> If the semanage is done after the useradd (could be 
> weeks after), 
> > >> the user could have files that live outside the home 
> directory (I 
> > >> think Dan pointed this out to me) so what files and directories 
> > >> would you run restorecon on?
> > >
> > > Also for a MLS environment you can't just relabel the 
> files unless 
> > > the new sensitivity label dominates the old.  For a strict policy 
> > > system it's generally acceptable for relabel the files, 
> but for MLS that won't work.
> >
> > you can if the thing relabeling is mls privileged, the 
> useradd program 
> > or whatever labels the home directory would have that privilege
> 
> Sure, you can break whatever security goals you might have if 
> your process is sufficiently privileged.  You can turn off SE 
> Linux too if that's what you desire.
> 

Useradd is clearly a privleged app already.

> But if your aim is that s15 data never gets relabeled to s0 
> then you are limited in what you can do if you want to 
> achieve your aim.
> 

With such a secure setup you should be administering it correctly and
your users will never have files with the wrong level.


--
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: User home directory creation with useradd (rhbz#217441)

[Linda Knippers]

>>> The sys-admin is wanting to create an entry for a user who 
>>> can login.  They don't want to think about creating a home 
>>> directory, creating a group, a user, a home directory, a SE 
>>> Linux user, and a SE Linux login mapping entry.
>>> 
> 
> 
> Doesn't matter, semanage doesn't need any more feature creep than it has
> right now.

I don't want more stuff in semanage.  We should be able to do it from
useradd, and from one role.  Right now its a multi step operation and
we can't run useradd and semanage from the same role.  Only sysadm_r
can run useradd and only secadm_r can run semanage with the current
MLS policy.

I've also noticed that only secadm_r can change the selinux context
of a file (makes sense) but secadm_r can't change the mode bits of
the same file, only sysadm_r can.  That doesn't make sense to me.
I don't know if that's a bug, a feature or a configuration problem
on my system (and is somewhat off-topic) but its another example of
illogical behavior.  Seems like secadm_r can do SELinux things but
not other security administration unrelated to SELinux, and that
makes SELinux look like a wart rather than an integrated feature.

Ok, here's another example.  secadm_r can manage policy but can't
'touch /.autorelabel', only sysadm_r can do that.

-- ljk

--
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: User home directory creation with useradd (rhbz#217441)

[Joshua Brindle]

> From: Linda Knippers [mailto:linda.knippers@hp.com] 
> 
> >>> The sys-admin is wanting to create an entry for a user who can 
> >>> login.  They don't want to think about creating a home directory, 
> >>> creating a group, a user, a home directory, a SE Linux 
> user, and a 
> >>> SE Linux login mapping entry.
> >>> 
> > 
> > 
> > Doesn't matter, semanage doesn't need any more feature 
> creep than it 
> > has right now.
> 
> I don't want more stuff in semanage.  We should be able to do 
> it from useradd, and from one role.  Right now its a multi 
> step operation and we can't run useradd and semanage from the 
> same role.  Only sysadm_r can run useradd and only secadm_r 
> can run semanage with the current MLS policy.
> 
> I've also noticed that only secadm_r can change the selinux 
> context of a file (makes sense) but secadm_r can't change the 
> mode bits of the same file, only sysadm_r can.  That doesn't 
> make sense to me.
> I don't know if that's a bug, a feature or a configuration 
> problem on my system (and is somewhat off-topic) but its 
> another example of illogical behavior.  Seems like secadm_r 
> can do SELinux things but not other security administration 
> unrelated to SELinux, and that makes SELinux look like a wart 
> rather than an integrated feature.
> 
> Ok, here's another example.  secadm_r can manage policy but 
> can't 'touch /.autorelabel', only sysadm_r can do that.

This isn't surprising, secadm_r was pretty much an afterthought..

--
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: User home directory creation with useradd (rhbz#217441)

[Russell Coker]

On Sunday 03 December 2006 06:29, "Joshua Brindle" <jbrindle@tresys.com> 
wrote:
> > Ok, here's another example.  secadm_r can manage policy but
> > can't 'touch /.autorelabel', only sysadm_r can do that.
>
> This isn't surprising, secadm_r was pretty much an afterthought..

...to the entire design of the Unix OS and to OS design in general.

-- 
russell@coker.com.au
http://etbe.blogspot.com/          My Blog

http://www.coker.com.au/sponsorship.html Sponsoring Free Software development


--
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: User home directory creation with useradd (rhbz#217441)

[Russell Coker]

On Sunday 03 December 2006 06:21, Linda Knippers <linda.knippers@hp.com> 
wrote:
> Ok, here's another example.  secadm_r can manage policy but can't
> 'touch /.autorelabel', only sysadm_r can do that.

The idea of separating sysadm and secadm fundamentally isn't viable.  The only 
separation is an advisory separation (similar to the way that some security 
people demand that tcpdump not be installed on servers so that sys-admins 
can't sniff data).

The sys-admin needs to be able to perform actions such as running debugfs as 
part of their work.  This permits them ultimate access to the system 
regardless of what SE Linux does.  The sys-admin also needs to be able to 
control the system boot process, and again it gives them ultimate access.

It is quite possible to have a locked-down system that no-one can alter 
without physical dis-assembly - but that does not require limiting the 
sysadm_t domain (in fact it would be better to just not permit any user to 
enter the sysadm_r role).

The sysadm/secadm split is always going to be inconvenient and inconsistent.

-- 
russell@coker.com.au
http://etbe.blogspot.com/          My Blog

http://www.coker.com.au/sponsorship.html Sponsoring Free Software development

--
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: User home directory creation with useradd (rhbz#217441)

[Casey Schaufler]

--- Linda Knippers <linda.knippers@hp.com> wrote:


> I don't want more stuff in semanage.  We should be
> able to do it from
> useradd, and from one role.  Right now its a multi
> step operation and
> we can't run useradd and semanage from the same
> role.  Only sysadm_r
> can run useradd and only secadm_r can run semanage
> with the current
> MLS policy.

While this is inconvenient, it is consistant
with the separation of roles. You might want
a role explictitly for this function.
Experiance on other systems has been that
neither the secadm nor the sysadm roles are
sufficient for adding a user by themselves,
nor should they be.

> I've also noticed that only secadm_r can change the
> selinux context
> of a file (makes sense) but secadm_r can't change
> the mode bits of
> the same file, only sysadm_r can.  That doesn't make
> sense to me.

When roles are defined in the context of an
implementaion logical associations don't always
apply. Since SELinux and the policies it
enforces are implemented as an adjunct to the
traditional mechanisms binding a relationship
to their administration is challanging.

> I don't know if that's a bug, a feature or a
> configuration problem
> on my system (and is somewhat off-topic) but its
> another example of
> illogical behavior.

It's illogical only in the context of security
policy integration. Each set of policies are
completely consistant, however the differences
become evident when placed in such proximity.

> Seems like secadm_r can do
> SELinux things but
> not other security administration unrelated to
> SELinux, and that
> makes SELinux look like a wart rather than an
> integrated feature.

Indeed, but take heart as this problem has
come up with Unix MLS systems as well. We
actually dropped the active persuit of roles
in one system because there just didn't seem
to be a useful separation between the system
and security admins, with the exception of
the auditor, which we kept.

> Ok, here's another example.  secadm_r can manage
> policy but can't
> 'touch /.autorelabel', only sysadm_r can do that.

You are seeing the reality of implementation
getting in the way of behavior matching what
a "designed" system ought to do. There are
ways to fix this, but they're expensive and
probably not viable upstream (yet).

So, I don't see that you're going to have
much luck addressing these issues in the
short term as they are artifacts of the
implementation. You might do well to put
some effort into explaining why these
behaviors are rational and necessary in the
context of role separation.


Casey Schaufler
casey@schaufler-ca.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: User home directory creation with useradd (rhbz#217441)

[Karl MacMillan]

Casey Schaufler wrote:
> --- Linda Knippers <linda.knippers@hp.com> wrote:
> 
> 
>> I don't want more stuff in semanage.  We should be
>> able to do it from
>> useradd, and from one role.  Right now its a multi
>> step operation and
>> we can't run useradd and semanage from the same
>> role.  Only sysadm_r
>> can run useradd and only secadm_r can run semanage
>> with the current
>> MLS policy.
> 
> While this is inconvenient, it is consistant
> with the separation of roles. You might want
> a role explictitly for this function.
> Experiance on other systems has been that
> neither the secadm nor the sysadm roles are
> sufficient for adding a user by themselves,
> nor should they be.
> 

It should be configurable via policy, which means the code should be 
present in useradd. The vast majority of SELinux systems shipped don't 
have a secadm role. For that configuration the sysadm should be able to 
create a user and a user mapping in a single step.


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: User home directory creation with useradd (rhbz#217441)

[Casey Schaufler]

--- Karl MacMillan <kmacmillan@mentalrootkit.com>
wrote:

> Casey Schaufler wrote:
> > --- Linda Knippers <linda.knippers@hp.com> wrote:
> > 
> > 
> >> I don't want more stuff in semanage.  We should
> be
> >> able to do it from
> >> useradd, and from one role.  Right now its a
> multi
> >> step operation and
> >> we can't run useradd and semanage from the same
> >> role.  Only sysadm_r
> >> can run useradd and only secadm_r can run
> semanage
> >> with the current
> >> MLS policy.
> > 
> > While this is inconvenient, it is consistant
> > with the separation of roles. You might want
> > a role explictitly for this function.
> > Experiance on other systems has been that
> > neither the secadm nor the sysadm roles are
> > sufficient for adding a user by themselves,
> > nor should they be.
> > 
> 
> It should be configurable via policy, which means
> the code should be 
> present in useradd. The vast majority of SELinux
> systems shipped don't 
> have a secadm role. For that configuration the
> sysadm should be able to 
> create a user and a user mapping in a single step.

Hmm. It that case you could rename the role,
maybe something simple and easy to spell.

How about "root"?

I started out on this thinking that I was
being clever, but I seriously think that is
what you ought to do, rather than trying to
define some role that is somehow restricted
yet able to add users. If the arguement is
that separated roles are too hard to deal
with* and that many people won't deal with
them, I say accept it, acknowlege it,
accomodate it, and move on.

------
* I don't like administrative role separation
  myself, but my predjudices are based on a
  long history with Unix and many many (mostly
  really bad) administrative interfaces.


Casey Schaufler
casey@schaufler-ca.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.