theoretical question - can root's username be changed?

[Guy Fraser]

On Thu, 2005-01-12 at 23:17 -0600, Mike McCarty wrote:
> John Summerfied wrote:
> > Mike McCarty wrote:
> > 
> >>> Let me put it differently. Root's UID is 0 - suppose I change UID 0's 
> >>> User Login to 'doorknob' - first, can this be done? Second, would I 
> >>> have to create a new home directory called 'doorknob'? Third, are 
> >>> there any implications, doing this, for other software and/or 
> >>> settings in a Linux PC? Fourth - if this shouldn't be done, can a new 
> >>> user, say UID 15, be created with all the same privileges as root, 
> >>> and can root then be purged?
> >>
> >>
> >>
> >> You may have as many user names associated with UID 0 as you like.
> >> The home directories may be set independently as you like.
> >> I would not "purge" UID 0, but I cannot think of how that would
> >> conflict.
> > 
> > 
> > There is another problem resolving UID=0 to a name
> > 
> > Which name?
> > 
> > At one point I had "john" and "summer" with the same UID and it did not 
> > work very well at all.
> 
> Yes, I can believe that. I did some contract work for a company
> doing pharmeceutical control software, which had a user with
> UID 0 on UNIX like systems. There were three major flaws in
> security: (1) ordinary users were forced to log in with
> what was essentially root (yes, it was a different name,
> and the password was different, and they didn't even know
> they were logged in, but still, all the software ran with
> root access, and defects could be devastating), (2) it was
> difficult to ascertain just who and what actually did something
> to the system, since everything was reported as "root", and
> (3) remote access required security compromise when doing debug
> work, since one had to log in as essentially root to do
> any work.
> 
> > A really big flaw in Unix design is the fact one user has the inherent 
> > ability to do everything, the fact that the Unix security model is built 
> > round this.
> 
> I think it goes a little deeper than this. The entire security
> system is based on a very simple model: owner, trusted friends,
> everyone else. So root is just a "universal owner".
> 
> > The windows model is, to my mind better; where it falls down is the 
> > implementation.
> 
> The Windows NT (and hence XP) model is superior, yes.

I would not agree with that 100%, but there are some good 
things about the user/group system used by some NT systems.

> 
> > I used to  be an MVS sysprog (20 years or so ago). The right/ability to 
> > create new accounts was given to individuals (sure, they can create 
> > users with any rights at all, but in fact there aren't many rights in 
> > MVS, and on those machines people cared about security and implemented 
> > audit trails).
> > 
> > Some of us sysprogs "owned" the system libraries, and it was the right 
> > of ownership that gave us the ability to install/udate programs. And 
> > they were protected by passwords and expiry dates, the latter requiring 
> > intervention from operators to okay.
> > 
> > It was way more complicated than that, of course, but it helps 
> > illustrate an alternative security model.
> 
> Another is the Access Control List model. I have used ACL on
> more than one system. It is much more flexible, and allows
> users (yes, lowly users, not "root" users) to control their
> own files with as much finesse as the sys admin can control
> the system files. But, of course, what one gets on one end
> one loses on the other. ACL management is more complex and
> time consuming than just user/group/world and root is
> a pseudo owner for every file, and requires more knowledge
> on the parts of those who use is, which can actually be
> a disincentive to use it. ANY technique, if not used, is
> inefectual.

That is what SELinux provides, and more. Unfortunately SELinux 
seems to be complicated to configure and difficult to use. I 
have tried a couple of times to work with it, but the 
documentation and tools are not simple to use or work with.
I only have one RHEL server, that I help to maintain on a 
consulting basis, and all the other servers I maintain are 
not running Linux anymore, so I don't have the time to 
read all the necessary documentation in order to fully 
understand how to properly configure and maintain SELinux.

Possibly with a simplified tutorial and simpler tools 
the ACL configuration of SELinux can provide the Best of 
Both Worlds.

The standard Linux Kernel also supports ACL natively, but 
the userland tools have been elusive.