Default shell for root and users is different

You have ignored the bit where I said "my preferred shell, profile, and aliases, all ready to go in an emergency".
You have ignored the bit where I said “init(8) asks for the shell to run”. ;)
So, if your preferred shell is /bin/ksh, then you enter that. I don’t see a problem here.

You are right that such preparations tend to be rarely used. But it only takes one major incident...
I had such incidents in the past, both at work and at home. But I don’t think I’ve ever had to spend more than 15 minutes in single-user mode in order to fix things in a way so I was able to boot multi-user again and log in normally.

Actually I’m a zsh addict and make heavy use of advanced zsh features, e.g. I’ve written a lot of custom completion functions, dynamic aliases and things like that. When people watch me typing, it often looks like magic to them. :) However, I still know the standard /bin/sh well enough to be able to work with it for 15 minutes in an emergency situation. This happens once in several years, so it’s just not worth the effort to build an advanced root environment just for single-user mode; that would be a waste of time, IMHO. As I wrote previously, I have a habit to keep a statically linked binary of zsh in /rescue (my update script does this automatically whenever zsh is updated), but I rarely ever use it.

YMMV, of course.
 
I have never worked in a place where root logins were disabled.
Root passwords were usually kept in a password safe (one place actually had a physical safe), with restricted and audited access.
But if the LDAP servers went down, the root login (which was the only local login) would be your only way in.
And when the LDAP servers were Linux boxes, you can see the Catch 22 we are avoiding...
Maybe you haven’t worked at places that were extremely concerned about security. I always give the advice to disable root logins completely. They are already disabled by default via ssh, but it’s also advisable to disable local root logins.

If things break in a way that you cannot log in normally anymore – including LDAP servers going down –, you can still boot into single-user mode. No root login required. (At least not with FreeBSD, but I guess Linux is similar enough in this regard). Of course, you can (and should!) configure your machines so that the root password is required for entering single-user mode, and this password should be kept in a safe place, as you described above. And also, the machines should be physically secured, to prevent someone from booting via USB stick or similar.
 
It is lesser known that you can use any shell as root shell without any problem.
Just make sure you have a staticly linked toor shell for the toor recovery user, e.g. mksh or oksh.
 
You have ignored the bit where I said “init(8) asks for the shell to run”. ;)
So, if your preferred shell is /bin/ksh, then you enter that. I don’t see a problem here.
By default, the Korn shell does not install into the root, nor is it statically linked.
My point was that it takes prior planning with specific intent and effort to make it so.

However, I still know the standard /bin/sh well enough to be able to work with it for 15 minutes in an emergency situation
I am quite familiar with /bin/sh. In fact, the Bourne shell was my first shell, and I learned it on a hard copy DEC LA120.
I also to hope to limit my emergencies to 15 minutes, but still plan for the worst ;).
 
I used ksh on AIX where it was the native default shell, and I loved it, but I always use the native default shell for interactive use. For scripting purposes I only use sh and that's mainly for cross-platform compatibility's sake and because it's a very fine shell.
 
Maybe you haven’t worked at places that were extremely concerned about security.
I can't tell you where I have worked. But I can say that security was taken seriously.
If things break in a way that you cannot log in normally anymore – including LDAP servers going down –, you can still boot into single-user mode. No root login required.
That might be a satisfactory solution if unscheduled downtime is permitted.
 
For scripting it is key that you learn one shell. Because different shells have sometimes subtle nuaces and differences.
It really does not matter which shell you use. I use zsh because it has a lot of functionality.
It is said you should use sh for portability. But every shell script is portable to the same shell.
 
By default, the Korn shell does not install into the root, nor is it statically linked.
My point was that it takes prior planning with specific intent and effort to make it so.
Well, yes, to a certain degree. In the case of zsh, I just compile the port with STATIC=yes and copy the resulting binary to /rescue. Not a big deal. As I mentioned previously, my update script does that automatically.
 
If the services running on those machines are important, then there should be redundancy, e.g. a cluster of servers.
The issue is that your position (disabling root login) can require an unscheduled outage to resolve an issue -- whereas mine may not. You have therefore increased the risk of service failure.
Multiplying the lines of service reduces the risk. It does not remove it entirely, because circumstances may conspire to bring down an entire cluster of servers, all compromised for exactly the same reason.

If you are "extremely concerned about security", then disabling root login should not be recommenced without due consideration of the risk profile and mitigating factors. You really do risk shooting yourself in the foot.

I am not saying that root logins should ever be considered routine. But they can save you from an outage in an emergency.

An example of an environment that is extremely concerned about both security and continuity of service is where all system logs are collected and analysed in real time by an independent security team, so root logins are all observed (along with all sudo(8), and similar, activities) actively looking for any sign of malfeasance.
 
The issue is that your position (disabling root login) can require an unscheduled outage to resolve an issue -- whereas mine may not. You have therefore increased the risk of service failure.
Multiplying the lines of service reduces the risk. It does not remove it entirely, because circumstances may conspire to bring down an entire cluster of servers, all compromised for exactly the same reason.
I have to say I never experienced such a situation in 25 years. What kind of problem would require a root login, while at the same time it doesn’t cause a service downtime anyway? You mentioned LDAP – Well, if all of your LDAP services are down at the same time, and root is your only non-LDAP account (which would be a very bad idea, by the way), then your services are probably down anyway because authentication doesn’t work anymore.
 
I have to say I never experienced such a situation in 25 years. What kind of problem would require a root login, while at the same time it doesn’t cause a service downtime anyway? You mentioned LDAP – Well, if all of your LDAP services are down at the same time, and root is your only non-LDAP account (which would be a very bad idea, by the way), then your services are probably down anyway because authentication doesn’t work anymore.
When an organiation gets large enough, the staff moves and changes need to be centrally managed so there is a highly secure single source of truth for accounts, authorisations, and password.

This is typically done with some combination or adaptation of Kerberos and LDAP, which rely on the network for their function.

There are many reasons why the LDAP servers may become inaccessible -- and those reasons go well beyond the risks that can be managed by clustering or running multiple lines of LDAP service.

There have been many occasions where I have seen a Unix host disappear from the network, suddenly and unexpectedly.

When you have hundreds of VMware servers, dozens are going to get replaced every year with the ongoing hardware replacement programme. This provides a common source if problems -- because it's really hard to test properly before new server is commissioned.

When a Unix VM disappears from the network, your only way in to that Unix system is via the virtual console furnished by the VMware server. You have no network, and therefore no LDAP authentication, so you can't login as yourself, and you absolutely need a local root login to diagnose the problem. The most usual cause of this problem is a recent VMotion of your Unix VM to a new VMware server configured without the VLAN(s) your Unix VM needs to operate on its network(s). The second most common cause is that the firewall team got the firewall rules wrong for the list of VMs that may be migrated to the new VMware server. Host-based firewall rules on your Unix VM may also come into play, but that's far less common.

Such problems do not justify shutting down the Unix VM (and losing state and any stalled transactions) because the network is down and you can't login! All you have to do is is fix the network issue(s).

Besides, shutting any system down without a pre-approved scheduled outage would most certainly result in a Quality Assurance non-conformance notice arriving in your in-box.

So, there exist circumstances where root logins are both desirable and necessary.
 
Back
Top