[Freeipa-users] ipausers default group

[Simo Sorce]

On Tue, 2008-11-18 at 11:34 -0430, Robert Marcano wrote:
> On Tue, 2008-11-18 at 15:00 +0000, Simo Sorce wrote:
> 
> > There are many things that need to be configured properly to avoid
> > security issues, this is just on of them, maybe we should make it better
> > known in the docs.
> 
> I do not buy this either, this is like if Red Hat Enterpise Linux docs
> say me that in order to have more security i need to change the umask,
> because the default is not good enough, and the adduser script just
> create by default users on the rhusers group.

A matter of Points of View in my opinion, I respect yours.
 
> > > So, Freeipa create a (little) insecure environment by default.
> > 
> > No, it is just a different environment, security depends on how well or
> > bad you configure your environment.
> 
> a different evironment whose defaults are less secure than a default
> RH/Fedora install, Freeipa (in its current state) can protect password
> being stealed on the net (Kerberos) but local security is less secure
> than a plain RH/Fedora installation

Given that Freeipa does not create home directories or set up the disk
layout in any way and that admins can easily use ACLs on the file system
to attain the level of security they prefer I do not think this to be a
freeipa problem, not yet.

When you configure your file system or home creation scripts you will
probably make sure user home directories are set 700.

> > We could make ipa-client-install to change the umask by default maybe,
> > and with v2 we should be able to have policies that do that on all
> > clients.
> 
> if V2 will do that, then the group per user issue is resolved, but it
> does not do that today, and by default current freeipa is insecure and a
> security advisory is needed (some temporary files could be writeable by
> any member of ipausers).

I don't think we need any security advisory.

> (note that I am a little extremist on file security issues
> https://bugzilla.redhat.com/show_bug.cgi?id=447430 )

Sure your right to be, but it's your decision. Admins are free to adopt
whatever default they prefer and manage file access and umasks the way
they choose. Eventually overriding defaults.

> > >  I
> > > understand that things must be made easy for the users but remember that
> > > making things easier can compromise security too.
> > 
> > Making things more complex the same, sorry I do not buy the argument
> > that easier = less secure, I wouldn't have worked on the FreeIPA project
> > at all if I thought that.
> 
> I am not saying the UI must be made complex, but simplicity means to be
> more careful of what you do, because you do not give the options to the
> user to customize and blame him/her of any error.

changing umask in /etc/bashrc is not complex for any sysadmin.

> > Adding a group per user just to keep the umask 022 is honestly just an
> > hack, that makes managing groups cumbersome.
> 
> Could be, but do you not replace a hack without doing the real well done
> fix (freeipa removes the hack but does not change the umask)

We do not touch machines configuration too much in freeipa 1.x, we do
not even create home directories. It is very clear that file system
management is not a Freeipa goal in v1 and admins need to mange it
themselves.

> > > 
> > > That is the temporary solution that I will propose here, but I am sad
> > > because it will not be very welcome, because we lose the integrated GUI
> > > (the primary reason we opted for freeipa)
> > 
> > It would be easier to change the umask indeed it's not that difficult :)
> 
> again the easier argument, it is not easier, do things on a central
> location is easier or more manageable that changing the umask on each
> ipa client .

True, that's why we are adding policy support. But because you have to
install and configure the client to access IPA anyway, I cannot consider
changing another file an issue.

Also you may decide to do that in the single user profile instead, again
because you have to provision home directories yourself as IPA does not
do it, it is just a matter of adjusting your provisioning process.

> in summary, current freeipa needs a patch to set the umask to users
> whose primary group is ipauser (or uid greather than 1000?), until V2
> policies can do that

Yes I will consider adding something to that effect in
ipa-client-install so that it can be done at the same time the client is
enrolled.

> Just a note, umask is for the user session, not having a group per user
> will make that all services provided on the network must be checked, for
> example, all Samba shares "create mask" and "create directory mask" must
> be checked

I really think that ACLs (and default ACLs) is the real answer here,
umask has always been an issue, the right answer is to use proper ACLs
on the directories the user has access to for writing (normally only
their home and /tmp, so any other directory is custom made by admins).

The only reason why umask even exists is that back in the time unix
didn't have ACLs. We have them since long now, it's really time to start
using these tools to solve the problem at the right level.

As for /tmp I hope we will soon mode to have per user temp dirs which
will completely solve the umask problem even without changing it in the
default install.

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York