[cobalt-security] Re: [Qube2] Admin Account/changing admin login and security

[Diana Brake <diana@xxxxxxxxxxxxx>]

Mike Vanecek wrote:
<snipping before>
>However, after that, I am worried about the standard do everything userid
>account of admin. On NT systems one of the first things I do is set up 
another
>administrator account and then rename the original administrator account to
>something else. That way a hacker cannot try to find the pw for 
administrator
>since it does not exist.
<snipping after>

Hi Mike,

I've been thinking about your question...the way cobalt requires the admin 
and tying admin and root passwords together. NOTE: I have a RaQ2 NOT an 
Qube2. Maybe this will work for you anyway.

I'm a linux/cobalt newbie so my answer may be off the wall...but, I've 
implemented it on my system and nothing appears to be broken.

<background>
I created multiple system admins...not site admins...because of the 32 
group limit. I administer many of the sites on my machine and even if there 
is a siteadmin who admins his own site, I don't want my access abilities 
tied to his. So, I have an admin set up for sites 1-25, another for sites 
26-50, another for sites 51-75, etc. I had to edit the group file in 
/etc/group so I'm sure the warranty is void...:) So, I don't use the cobalt 
default admin for administering ANY of the vhosts on the machine. But, I 
don't use the siteadmin either...security from an overly inquisitive user 
who wants to find out what the trashcan icon does, or one who needs a 
password that is different from one I know...:) (aside: this does cause 
owner/permission problems with cgi-bins/scripts in local vhost 
directories..IF I place them there with MY adminID...but I usually just 
give instructions to users who do these things themselves with their own 
siteadmin ID ..solving that problem...and this is only a problem IF they 
want to install or overwrite what I install. Scripts will run fine from the 
browser even with my admin owning the scripts...otherwise..chown 
cgi-bin/files.)
</background>

Now to your question. Since I don't use admin for anything except base 
server administration, but everyone who knows anything about cobalt knows 
admin shares the root password, I figured, take admin out of the wheel line 
in the group file. I placed one of my secondary (for lack of a better 
description) admin IDs in the wheel group instead. I can still telnet in as 
admin...using the current/proper password. BUT, admin can't su to root now. 
The passwords are still the same...but someone would have to "guess" what 
ID I've designated to be able to su -.  My admin CAN su newadminID...who 
can then su root...but nobody but me knows which ID I've allowed this 
privilege. GUI still works. Telnet still works. (I am the ONLY one on the 
whole system with telnet privileges). So, I "feel" that I've partially 
protected myself anyway. Again, the newbie that I am, I may be fooling 
myself...*grin...and I do still intend to install the SSH program  and shut 
off the telnet port.

I hope that helps and anyone, please point out inaccuracies or fallacies in 
my thinking. I didn't describe all the steps required so if this would help 
anyone, I will do this when asked.

thanks,
Diana
Crest Communications, Inc.		diana@xxxxxxxxxxxxx
Beautiful Sunny Florida		http://crestcommunications.com/
352-495-9359