Unix groups with no associated Unix accounts assigned: security risk?

[John Knapp]

In a recent security audit, we were cited for having some Unix
group accounts that did not have any associated unix user
accounts. We contend it is not a security issue but rather a
result of O/S & application vendors' software install results.

On a HP9000 K570 (v10.20) we have the following entries in /etc/group with no accounts assigned to it:

ocr_hpux.freedom.com (host)

tty::10:
nogroup:*:-2:
cdss::209:
mss::210:
adcentral::211:

1) Can you explain why we have tty & nogroup w/o accounts?
2) Is it a security issue?
3) How can we remove those groups w/o negatively affecting the
system or application?

[harry d brown jr]

Was the security assessment done by arthur andersen?

Seriously, "auditing" firms are a joke, and bunch of wanna-be's, that couldn't get a real job.

Have a look at these "papers":

http://people.hp.se/stevesk/bastion.html

live free or die
harry

[Helen French · Accepted solution]

Hi John,

1) The 'nogroup' and 'tty' are system specific groups. You SHOULD NOT delete those entries. 'nogroup' is being used by NFS services and 'tty' for the pty/tty services. These groups were created by the OS and you may leave it like that.

2) There is no security issues with these groups. There will be other issues if you delete them.

3) You can delete the other 3 listed groups, if you don't use them any more. Use SAM to remove these groups from the system. Normally the user created groups will have GID >= 101. Other groups are system specific and you can leave them as it is ( eg: root, other, bin, sys, adm, lp, tty, nogroup etc)

4) Make a copyt of the group file before making changes. Keep always a good make_tape_recovery tape !

HTH,
Shiju

[harry d brown jr]

A little follow up, in case someone get's offended by my slamming auditing firms:

I once had an "auditing" firm tell my client, a billion+ dollar bank, that they should remove all editors, and I was called, and I agreed that it is possible and I instructed them on how to do such.

A Day later, I was called and asked if we could remove the source code. Not a problem!

Another Day Later I was called and asked if we could remove the compilers. Again I agreed and led the way.

Again, another day later, I was called and asked if we could remove some other "STUFF". Now, I was getting sick and tired of the insanity, so I called the president and a few vp's of the Bank on a conference call with the auditor. I told the auditor that I could honor his request to remove the OBJECT code, and that I could do one better by removing the OPERATING SYSTEM and any references to the banks data. Needless to say, the auditing firm was fired for being completely idiotic and non-computer literate.


live free or die
harry

[Michael Tully]

Hi,

Arthur Anderson.... good one Harry! Security audits are a joke, we had one on a server just last week and didn't look for any files with any inappropriate permissions, like file owned by 'root' with permssions of 666!

Before removing the groups (cdss, mss, & adcentral) make sure that there are no files on your system that have group id. You can use the find command to get these.

# find / -group -print

HTH
-Michael

[John Knapp]

Thank you everyone for the info & the chuckle ;-)

[Patrick Wallek]

There is also another possibility. There may be users that have one of those groups defined as their default group in the /etc/passwd file, thus there would not be any users assigned to those groups in the /etc/group file.