single user mode and security- massive loophole???

[Mark Vollmers]

Hi, all. just a question that's been bouncing around in my head that I've been wondering about. Doesn't single user mode negate anything that you can do about security? For example, you can set up all your defenses, passwords, etc, but su mode gives root access without a password. I can see that is why you keep servers locked up, but what about workstations? I mean, ultimatly, couldn't I just walk up to any workstation, shut it off, boot it back up in su mode, and set root password? and then isn't root on a workstation set up to be root on a server, and thus I can do whatever I want (even if it isn't, the workstation is fair game), right? my point is that on NT, once the admin account is set up, I can't really get at it without the password, and a power cycle won't change that. It seems too easy. am I missing something? it's not like this is a concern, but I was just wondering if physical access to any unix box is a potentially huge frickin' security hole or not.

food for thought.

Mark

[Uday_S_Ankolekar · Accepted solution]

Well, If you convert system in to a trusted one then you can configure to change the Boot_authentication to ask for a password in a single user mode

-USA..

[PIYUSH D. PATEL]

Hi,

If you configure the system - trusted then it will definitely ask you for the password.

In the non-trusted mode, yes there is a security loophole.

Piyush

[Jeff Schussele]

Hi Mark,

I can't speak for others, but we DO NOT put .rhosts & .netrc files on the workstations such that you could gain access to servers w/o a PW. You'll still ALWAYS need to know the root PW on the servers. And of course those PWs are ALWAYS different from our workstation root PW. We also set up the securetty file on ALL servers & workstations.
In fact SAs are responsible for their W/S root PW & do not share them w/other SAs except on a need-to-know basis.
Yes that leaves workstations somewhat vulnerable, but here you need key-card access to our work areas as well as the data ctrs anyway.....

Rgds,
Jeff

[S.K. Chan]

All your points are valid and I doubt anyone would argue otherwise saying that this is not a security threat. The question is how to MINIMIZE the risk (other that physical locks and trusted environment) from a workstation standpoint. What if you got 200 workstations on the production floor which is wide open to a janitor-cum-hacker ? For our case we tried our best to address this issue ..
- paging notification if a machine goes down
- nightly password file timestamp check (NIS)
- system security awareness class
The threat is more likely to come from a disgrunted employee who's not happy at work :)

[Darrell Allen]

Hi Mark,

That's one of the marvels of HPUX! For any system, HP or not, physical security should come first. Booting without passwords, booting from CDs, etc are double-edged swords. Often to get our jobs done "You can't live with 'em and you can't live without 'em"!

And just like a chain, security for your enterprise is only as strong as your weakest link. If that's a physically non-secured workstation that has users with non-password access to servers and it can be booted into single-user mode without a password... You can see where that's going.

Darrell

[Keith Buck]

HP-UX Bastille can help implement some of the suggestions that others have given, including converting to trusted mode and setting a single user password. It even has information about the "secure boot option" which takes considerable effort to disable (and therefore can cause quite an inconvenience if you forget the root password)

A beta version of HP-UX Bastille is currently available from http://www.bastille-linux.org (click on "Download Beta w/ HP support")

Still, no matter what you do, if you don't have good physical security, you don't have good security. Anyone with a screwdriver can disassemble the machine and do whatever they want with the parts and data contained inside.

[Christopher Caldwell]

Physical security is a must. Given that you don't have physical security, you don't have a prayer of protecting your systems. Consider the case where you do have a single user boot password, but I can stick a tape in your tape drive, power cycle the box, and boot off the tape - now you've got a big hole.

Or how about the hole where I can't log in, but I can shutdown (power down) your box.

To fix these problems, prevent unauthorized personnel from getting physical access to the equipment (power switch, tape drives, CD-ROMS, etc.).

With workstations in an office environment, physical security might be trickier, because you're likely to have a collection of employees with a higher risk profile than the folks that operate an equipment room - maybe security cameras would help.

In the end, if you don't have adequate physical security, you've got no security at all. The OS/application hardening will all be for naught if you give me physical access to the box.

[Steve Lewis]

Some secure sites have a separate system whereby the user cannot use the keyboard or monitor without first swiping their ID card into a *separate* system. So they won't be able to log in as root without first identifying themselves to big brother. This brings the question of accountability and audit into the debate.
Yes someone can still dismantle the box, but these things can be designed to not work when changed are made.
Yes they can still power-off the machine, but how secure do you want it to be? Should you give these users the ability to power down any machine that stores important data? - No. What about tempesting, EMR, printouts, etc? the list rapidly expands.
All the previous postings give excellent advice.

[Bill McNAMARA_1]

You can password protect the BCH... but then again you can also pull the plug on a server... You servers should be locked up in a secure room if you are really worried about it! .. and root access only at console.. (wear your jumper to the cold room!)

Later,
Bill

[Mark Vollmers]

Ahh, I see. I thought that I was missing something about the whole deal. for one, I didn't know that you could set the system to require a password on boot, since most of the references here are just "boot to single user". I guess the rest is just a trade off of system security vs. user rights (for lack of a better term).

one question I still have is about the workstation vs server root account. I think I have it right, but I want to check (base off what was set up here). server A has root, password bob. workstation B has root, password tim. untrusted system. ws has mounted /home from the server, contains files, user directories, etc. fstab on ws has A:/home /home nfs rw,suid 0 0. If I have on the server in /etc/exports a line for /home that has in it the option "root=B", then the root account for the ws will act as the root account for the server. this would mean that if a file has root ownership and permissions (750, say), with this config, I can su to root on the w (use password tim) and remove this file. if that line is not there, then the only way to remove this file would be to go to the server. Do I have this right? what if I (as root on ws) put a file on /home? can the server root remove it (does it hold true in reverse?)

Thanks for the responses guys! I'd been wondering for a while, and I'd have spent forever trying to figure it out on my own.

Mark

[Wodisch]

Hi Mark,

even if you set the boot_admin secure mode, if somebody can access the box (physically, i.e. touching it), s/he can attach another SCSI-device with the same ID as your boot disk (to the boot SCSI-channel), toggle the power, get a SCSI-ID-conflict and thus turn off the boot_admin secure mode :-(

Or s/he can simply open the cabinet and steal the disk(s)...

Without physical access control there is NO security!!!

Just my $0.02,
Wodisch

[Steve Lewis]

Mark,

Your fears over NFS are justified, since it is fundamentally insecure as has been pointed out in other forum threads. Don't exportfs anything in that manner. Don't put suid/sgid files in exported filesystems. Regulary check exported filesystems to ensure that other users haven't done such a thing. One customer I visited (a bank) even insisted that NFS was banned, .rhosts was banned and all non-root users had no access to chown/chmod! That policy certainly made life difficult for honest people.

Steve

[S.K. Chan]

You are right, with the access allow to root in exports file of server A, you can delete and create any files in /home from workstation B. If you do not have the "root=B" entry, you cannot create files in /home (as root) from workstation B and cannot delete files too which means the only way to delete it is to do it from the server itself. That is why having the access allow to root in /etc/exports file is not a good idea.

[Shannon Petry]

As others have pointed out, security at a physical layer is a must. I have scripts running on my servers which remove /.rhosts, and /etc/hosts.equiv to ensure network attacks are limited.

I dont care as much about workstations, as they dont hold user accounts nor data and applications. If a workstation is trashed, I can simply ignite them ;)

Your comment is not true about windows NT security either. I have 4 programs on Linux floppies for NT 3.5, 4.0, 2000, and XP admin hacks. The same problem exists. If i can get your box in my hands your done.
Dont forget that if an admin leaves the install disk in, i can run a quick recovery and steal your system as easy as you can get my Unix from single user mode.

Regards,
Shannon

[Mark Vollmers]

Much I have learned today, hmm?? Stronger can my security be.

sorry, channeled a little Yoda there :)

Thanks, all!

Mark

[Juan Manuel López]

The best you can do is to convert your system to " trusted system " with the command " tsconvert -c ".
There is NOT hole on single user, because there is root password on this mode, init 1.

I hope this help you.

Juanma.

[Steven Sim Kok Leong]

Hi,

Just to add on to what has already been said, Center for Internet Security has a HP-UX security benchmark for HP-UX 10.20, HP-UX 11.00 and HP-UX 11.11:

http://www.cisecurity.org/bench_HPUX.html

This benchmark comprises a list of hardening rules. These rules are very precise and clear. Will be good to check them out as well.

Hope this helps. Regards.

Steven Sim Kok Leong

[John Bolene]

Gotta have physical security along with software security.

We put all our production servers in the conmputer room.

No workstations or terminals can log into the servers without a login.

The logins expire after 30 days and the sane password cannot be used for 7 times. We spend a bit of time changing passwords every 3 weeks.