Re: [suse-security] User private groups?

On Mon, Jan 09, 2006 at 06:55:58AM -0500, Alex Hargrove wrote:

Hi Susan-

Thanks for the reply, that clears it up some... I am coming to SUSE from the NetWare world, where by default users can't see anything except those files/dirs that they have been explicitly given rights to (or through inheritance from a parent dir), so this is all sort of new to me.

Thanks again! Alex

...

...

...

Susan Dittmar 01/09/06 3:04 AM >>> Quoting Alex Hargrove (ahargrove@cgresd.net): Sorry, I guess I wasn't very clear. I intentionally asked why SUSE doesn't do this, because RedHat does by default. To me, it seems more secure to use User Private Groups, unless I am missing something...

I can't see why this makes the system more secure.

How secure your system is (with respect to groups) is decided by what members of the 'users' group may do. That you can reduce to a minimum, if you want to increase security.

Otherwise, 'users' is just the one group every true user is in (as opposed to the pseudo users for special services, like wwwrun and such). Giving something to that group just means giving it to every true user. And for anything else, there's the option not to allow access for any group (via chmod and umask) or to another, more restrictive group.

If you are comming from a BSD based system, the practice there is to create user owned groups instead of the general 'users' group. The BSD folks has a solid set of reasons for doing so dealing with the whole of they way systems were administered. take the example of adding users to a system. the default on suse is to create the user directory owned by user and owned by group 'user'. Group 'user' has rx permissions. World ALSO has rx permissions. The BSD folks will argue that all this is tunable via configuration files and adduser scripts, etc. Thats true. However, if your practice has been to RELY on the BSD way (and you have removed any world permissions via the config files) it is CRITICAL to understand the difference in the way Suse does things or you will not know you have a security hole to close. (I know there are linux distro's with create user owned groups the BSDish way (maybe debian?))

Just my 2c,

Susan

PS: While re-reading this, one scenario came to my mind where you might be lazy enough to want something like that.

Suppose you have a directory structure which is shared by a group of users. There, for the directories, the group-s-bit is set, making sure that anything created there belongs to the same group as the directory wherein it's created. Now if something is created there, you want the group-write-bit set, so the rest of the group can change it. So you set umask to something very open, giving automatical write access to the group.

So far, everything is fine. But, if you are lazy, you leave that umask active even when working in other directories. Now giving group-write-access is a rather insecure thing (which it might be in the shared directory aswell, but that's another toppic), which can be, at least to some extent, remedied by giving each user an unique group.

Still, I would rather think about, for example, a cronjob opening up those files newly created in the shared directory for the group than opening up everything by setting the default-umask to something this open. There might be programs relying, for the security of their data, on the standard 0022 umask (which they then should check, of course, but we all know that even programmers are users, and as lazy as users).

-- Check the headers for your unsubscription address For additional commands, e-mail: suse-security-help@suse.com Security-related bug reports go to security@suse.de, not here

-- Check the headers for your unsubscription address For additional commands, e-mail: suse-security-help@suse.com Security-related bug reports go to security@suse.de, not here

-- David Bear phone: 480-965-8257 fax: 480-965-9189 College of Public Programs/ASU Wilson Hall 232 Tempe, AZ 85287-0803 "Beware the IP portfolio, everyone will be suspect of trespassing"