personal root accounts

[jim bidebo]

Ive seen some systems where each admin has his own user account, and then access to an own root-account via su. This root-account is only possible to use via su, and only from the specific user account. (i belive that this was on a tru64 or digital unix system).

Does anyone know if this is possible to do in hp-ux (10.20)? and if its possible, how?

[Joseph C. Denman]

Jim,

I don't use it, but there is an application that will perform this task for HPUX. It is called psuedo...su-do....psu-do???? I cant remember the name. Do a search, I bet you will find it.

Hope this helps.

...jcd...

[S.K. Chan]

You can setup your system quickly in such a way that "root" can ONLY login from the system console. All you have to do is create a file called /etc/securetty (root:bin with 600 permission) and in that file put the string ..

console

That way the only way normal users can't login directly as root to the system unless they are physically login in from the console, or remote console.

[harry d brown jr]

Our SA's have to "su" up to root and enter a description on what and why they are doing such. It's a perl script that logs the stuff.

live free or die
harry

[David Burgess]

Giving a user uid 0 makes them root. It works, but I wouldn't recommend it. You could put a user in all the groups that root is in. Again not good.
The reason for using su / su - for root access is to have an audit trail. If everyone logs in as root you won't be able to see who that user really is.
Also giving everyone root access even with their own account is a bit too much for me. I like to know who's using root and only if they really need it.

Also if you create /etc/securetty and put the entry console in it you will only be able to login directly as root from the console. This will force all users to login as themsleves and then su to root.

HTH

Dave.

[pap]

Hi,
it is through SUDO.
You can install SUDO , its freeware and you can give certain administrative commands to general user if you want to give access to them.

Its a good tool though, I never used it.

http://www.courtesan.com/sudo/www.html

visit the site for more information.

-pap

[David Burgess]

Forgot to say. If you want users to do root stuff and not be root you can set a restricted SAM for them.

See man sam and the -r option.

HTH

Dave.

[MANOJ SRIVASTAVA]

Hi Jim

Here is a simple way to do it , put the following in /etc/profile , the system will not allow anyone to enter as root , they have to su to root and thus you can know who logs in by checking the su log :

loginid=`who am i | awk '{print $1}'`

echo $loginid
if [ $loginid = root ]
then
exit
fi


Manoj Srivastava

[jim bidebo]

do you mean sudo? but it does only allow a user to perform an action as root.

like:
$sudo vi /etc/passwd
will allow the user to edit /etc/passwd as root (if the user is specified in the sudoers file and suplie the right pass).

what i want is to have personal root accounts.
so i dont have to backtrack the root user to se which ip it was logged in from when he performed a task, and then trace the ip to see which mashine it is... and so forth untill i reach the person who did something.

[Joseph C. Denman]

Jim,

I don't think there is a way to create personal root accounts. I believe sudo has the option of logging the task. At least then you could track down who is doing what. I would not give users a uid of "0"...bad security practice. You can't track anything.

Good Luck

...jcd...

[S.K. Chan]

I've seen before how personalized root account is setup (after /etc/securetty is place).. though not a good idea .. eg: of a password entry ..

jimsu:XXXX:0:3::/root/users/jimsu:/bin/ksh

That way user "jim" only knows his "root" account password if you will and everything he does is "localized" to his .sh_history file.

Do you really want to do this ?

[jim bidebo]

well as always im a litle "wuzzy". Ill try to exlain it a litle more detailed.

lets say that we have a user that should have root priviledges. the users name is john doe and his ordinary user account is jodo. the jodo account does only have normal user priviledges, not member of any system groups or so. so to get root priviledges to him i would like to create a new account called jodoroot. the jodoroot account should only be possible to use by john doe when hes logged in as jodo and use 'su jodoroot'. so it shouldnt be possible to login as jodoroot right away. nor should it be possible for an other user to su to jodoroot. and the systems root account shouldnt be used at all for normaly actions, only when the system requires root to login (like in singleusermode).

[Jim Turner]

Hi Jim,

We use the Access Control portion of CA's E-Trust product. The part that is relevant to your question is a command called "sesu". Our SysAdmins log in with their mere mortal (non UID 0) account then sesu to root. When doing this, they are prompted for their own password -- not root's password.

After sesu-ing to root, the SysAdmins operate as root in every respect. However, they're leaving thier own fingerprints in the E-Trust audit logs for everything they do. The SysAdmins work unimpeded as root, and audit/security is frothy with delight over being able to see what is being done by each person.

We do limit native root logins to /dev/console only via /etc/securetty. Keep in mind, however, that we can ssh to a server with a mux that's connected to all the console ports -- very convenient. If a native root login takes place on the console port, the SysAdmin is prompted for name and reason for root access. The information is logged to a separate (secure) host.

Cheers,
Jim

[jim bidebo]

if i restrict root to /dev/console

creates a nonprivileded user account called jibi
and a root account called jibiroot and add :

case $_ in
jibi)

;;
*)
echo "Your not jibi! bye!"
exit
;;
esac

to .profile in jibiroot's $HOME

does anyone see any security issues in this procedure? does anyone have any better sugestions?

[Darrell Allen]

Hi Jim,

/etc/securetty will dis-allow any superuser (uid 0) account from logging in from any terminal other than those it allows.

You can only su to an account if you know the password or if you are already a superuser.

Any account with uid 0 is a superuser. You can specify multiple superuser accounts in /etc/passwd.

So far, so good.

I believe most will recommend against personal superuser accounts. If you have multiple superuser accounts, you have multiplied your security risks. Now you have multiple passwords that could be compromised, multiple .rhosts files, perhaps multiple superuser passwords to change if someone leaves, etc. If you just want to see who did what then you have /var/adm/sulog and /var/adm/syslog/syslog.log to rely on. Hopefully you don't have many users logging in as a superuser at the same time. If so, that's a different problem.

Of course, any superuser can cover his tracks if he desires.

Darrell

[harry d brown jr]

You can do this in their SPECIAL root account .profile, like joboroot:

sudo exec /usr/bin/ksh

gives them a root ksh and when they exit they get logged off.

live free or die
harry

[jim bidebo]

hmm.. thought my idea was pretty secured.

in a normal case senario:
cracker gets his hands on a user account.
cracker cracks root

in my vision senario: =)
cracker gets a user account. tries to crack root, but root isnt possible to login from anything except /dev/console, not even su to root should work. (sure he can probably get root by doing a bufferoverflow or something like that). otherwise he have to gain access to an account that has a personal root account. and thats 2 different passwords to crack.

well, its not uncommon that a user types down their pass on a paper, and trows it away without maculate it first (and makes it possible for a cracker to gain access by dumpster diving or similiar). hopefully persons with superuser priviledges doesnt do this. especially when they chose their own superuser password.

so by creating several uid 0 accounts it would actually increase security?

[harry d brown jr]

jim,

Great topic:
http://forums.itrc.hp.com/cm/QuestionAnswer/1,,0x96b70bce6f33d6118fff0090279cd0f9,00.html
http://forums.itrc.hp.com/cm/QuestionAnswer/1,,0x316efd3f91d3d5118ff40090279cd0f9,00.html

Great help in finding them:
http://forums.itrc.hp.com/cm/QuestionAnswer/1,,0x1e6f84534efbd5118ff40090279cd0f9,00.html


live free or die
harry

[harry d brown jr]

Jim,

By no means would I ever add another "root" user to a system by creating 0 uid accounts. That is the LEAST secure method, hell it creates more opportunities to "crack" a root account's password.

live free or die
harry

[jim bidebo]

harry:

i have given points to the answers that has been worth any points. and the only post that has been deserving any points is jim turners post. all the other things i did already know, or didnt filled any function in what i want to achive.

[jim bidebo]

harry:

well...
in a normal case senario any user can attempt to crack root (uid 0).

what i want to achive is that only jibi can crack jibiroot. so to be able to get root in my system you first have to gain access to jibi, and after that you can start trying to get access to jibiroot.


so lets say we have 200 users, and 5 users that should have root access.

in a normal system that means 200 different ways to gain root access, even thou theres only one password that actually will give the root access. but this password is shared between 5 different persons, its pretty likely that one of this five persons also writes down this password on a paper.

in my idea it means that theres only 5 ways in. and they are the five superusers own normal user accounts. those 5 passwords are probably not written down anywhere either since the admin can chose whatever pass he wants.

think, which system would be the easiest to crack?

[Darrell Allen]

More superuser accounts = more passwords that could be broken = less secure system.

I think the argument of 5 people knowing a second, common password vs 5 people knowing a second, unique password is the same as "6 of one, half a dozen of the other". I don't think the likelyhood of someone jotting down the password increases or decreases.

200 users = 200 ways to get in. Then you either have 1 password to crack (root's) or you have 5 passwords, any 1 of which you could crack.

I don't believe there is a way (outside of maybe sesu - did that use to be AutoSecure?) to limit a user to only su to his designated superuser account. You still have 200 ways to get into the system. Any one of them can be used to crack a superuser account.

Trusted systems will help since the password is shadowed.

Darrell

[jim bidebo]

darell:

in my model, yes that right its 200 ways in anyway you do it.
but in a normal situation theres only one password to crack (root) after you have gained access to the system.

in my way theres first 1 of 5 passwords to crack, and when you crack one of those theres another password to crack thats.

normal:
200->1 = root

mine:
200->5->1 = root

hopefully the admin user that got one of the cracked password will notice that someone has gained entrance to his normal users account before the cracker gets access to his superuser account.

[Darrell Allen]

Don't forget that I don't have to execute jibiroot's .profile to su to jibiroot. Nor do I have to execute /etc/profile (or csh.login for csh users).

Darrell

[Clemens van Everdingen]

Hi,

In the following thread Bill Hassell explained perfectly why never add more then one root account to your system.

http://forums.itrc.hp.com/cm/QuestionAnswer/1,,0x73a5ba808b46d611abda0090277a778c,00.html

C.