[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [suse-security] User private groups?



Quoting Alex Hargrove (ahargrove@xxxxxxxxxx):
> 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.

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@xxxxxxxx
Security-related bug reports go to security@xxxxxxx, not here