Impact of Deletion of Default users in HPUX

[Arun Jain]

Hi All,

As per following information (bin--sys--adm : These users don't "do" anything and normally all of these accounts are locked so that it is not possible to login as one of these users.),

I want to know the impact on general OS functioning if I remove all of them.

Best Regards:
Arun Jain

[Horia Chirculescu]

Hello,

Why should you remove those?

Horia.

[Arun Jain]

We have been given the requirement to remove unwanted users, even if they are system default users.

Regards
Arun Jain

[Kapil Jha]

These users are for system not for ordinary use.
They are necessary for various tasks (else they would not have been here----PURPOSE..)

http://forums11.itrc.hp.com/service/forums/questionanswer.do?admit=109447626+1265631679194+28353475&threadId=1177444

BR,
Kapil+

[James R. Ferguson]

Hi:

> We have been given the requirement to remove unwanted users, even if they are system default users.

Ask your auditors or your management if they obliterate all things that they don't understand. The link cited tells you why these accounts are present.

Regards!

...JRF...

[Johnson Punniyalingam]

adm
bin
sys

above mentioned accounts are called pseudo accounts, or you can call it "System default accounts" in layman terms
as per security audit measures, you should make sure these accounts do not have valid home directories and login shells because they are non-login accounts

Hope this helps you , better understanding and purpose of these accounts and you should able to explain to your auditors .

Regards,
Johnson

[Johnson Punniyalingam]

By tradition, the /etc/passwd file contains numerous (pseudo-accounts) which are entries not associated with individual users and which do not have true interactive login shells.

Some of these entries, such as date, who, sync, and tty, evolved strictly for user convenience, providing commands that could be executed without logging in. To tighten security, they have been eliminated in the distributed /etc/passwd so that these programs can be run only by a user who is logged in.

Other such entries remain in /etc/passwd because they are owners of files. Programs with owners such as adm, bin, daemon, hpdb, lp, and uucp encompass entire subsystems, and represent a special case. Because they grant access to files they protect or use, these programs must be allowed to function as pseudo-accounts, with entries listed in /etc/passwd. The customary pseudo- and special accounts are shown in Example 2-1.

Example 2-1 Pseudo- and Special System Accounts


root::0:3::/:/sbin/sh
daemon:*:1:5::/:/sbin/sh
bin:*:2:2::/usr/bin:/sbin/sh
sys:*:3:3::/:
adm:*:4:4::/var/adm:/sbin/sh
uucp:*:5:3::/var/spool/uucppublic:/usr/lbin/uucp/uucico
lp:*:9:7::/var/spool/lp:/sbin/sh
nuucp:*:11:11::/var/spool/uucppublic:/usr/lbin/uucp/uucico
hpdb:*:27:1:ALLBASE:/:/sbin/sh
nobody:*:-2:-2::/:


The key to the privileged status of these subsystems is their ability to grant access to programs under their jurisdiction without granting root access (uid 0). Instead, the setuid bit for the executable file is set and the effective user of the process corresponds to the owner of the executable file. For example, the cancel command is part of the lp subsystem and runs as effective user lp.

When the setuid is set, the security mediation of that subsystem enforces the security of all programs encompassed by the subsystem, not the entire system. Hence, the subsystem vulnerability to a breach of security is also limited to only those subsystem files. Breaches cannot affect the programs under different subsystems. For example, programs under lp do not affect those under daemon

for more information / imapct on removing the se accounts. please refer below document

http://docstore.mik.ua/manuals/hp-ux/en/5992-3387/ch02s04.html

[Steven E. Protter]

Shalom Arun,

Your auditors are clueless.

if they get their way your system will be very secure. This will be because it won't work any more.

SEP