topic Re: personal root accounts in Operating System - HP-UX

personal root accounts

jim bidebo — Tue, 30 Apr 2002 12:39:42 GMT

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?

Re: personal root accounts

Joseph C. Denman — Tue, 30 Apr 2002 12:47:15 GMT

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...

Re: personal root accounts

S.K. Chan — Tue, 30 Apr 2002 12:49:55 GMT

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.

Re: personal root accounts

harry d brown jr — Tue, 30 Apr 2002 12:50:31 GMT

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

Re: personal root accounts

David Burgess — Tue, 30 Apr 2002 12:51:39 GMT

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.

Re: personal root accounts

pap — Tue, 30 Apr 2002 12:53:14 GMT

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

Re: personal root accounts

David Burgess — Tue, 30 Apr 2002 12:53:50 GMT

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.

Re: personal root accounts

MANOJ SRIVASTAVA — Tue, 30 Apr 2002 12:54:21 GMT

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

Re: personal root accounts

jim bidebo — Tue, 30 Apr 2002 12:55:45 GMT

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.

Re: personal root accounts

Joseph C. Denman — Tue, 30 Apr 2002 13:06:46 GMT

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...

Re: personal root accounts

S.K. Chan — Tue, 30 Apr 2002 13:11:21 GMT

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 ?

Re: personal root accounts

jim bidebo — Tue, 30 Apr 2002 13:13:02 GMT

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).

Re: personal root accounts

Jim Turner — Tue, 30 Apr 2002 13:18:59 GMT

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

Re: personal root accounts

jim bidebo — Tue, 30 Apr 2002 13:40:19 GMT

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?

Re: personal root accounts

Darrell Allen — Tue, 30 Apr 2002 13:45:29 GMT

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

Re: personal root accounts

harry d brown jr — Tue, 30 Apr 2002 13:49:02 GMT

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

Re: personal root accounts

jim bidebo — Tue, 30 Apr 2002 14:00:31 GMT

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?

Re: personal root accounts

harry d brown jr — Tue, 30 Apr 2002 14:03:43 GMT

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

Re: personal root accounts

harry d brown jr — Tue, 30 Apr 2002 14:13:20 GMT

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

Re: personal root accounts

jim bidebo — Tue, 30 Apr 2002 14:13:57 GMT

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.