su

[TheJuiceman]

Hi again,

I am wanting to create a script so that some of our programmers can run in SAM-Lite. Basically I am wanting a script that will allow them to su as another user without being able to su as root or root equivalent (like lp, daemon, etc). However, I do not want to have to maintain a list of exclusions (or take the chance that I miss something...you know how things always change). Is there a way to do this? Thanks.

[TheJuiceman]

Oh, I also want to keep people from su'ing as a login that starts with a "d". How can I do that? Thanks again.

[Mic V.]

Have you thought about sudo? I'd have to take another look at the docs -- haven't done anything as detailed as you're suggesting -- but it might work. I've used sudo inside of SAM.

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

[TheJuiceman]

Thanks for the response. I was hoping to avoid sudo if possible. I really don't want to add any more third party software.

[Mic V.]

I know what you mean -- I always avoid open source software when building HA systems -- but this has always seemed like one I couldn't avoid. The alternative is to build my own, and I'm more confident in the state of a program that's been around and as scrutinied as sudo.

Perhaps if you explained more about what the programmers will be doing, someone might have another thought about how to implement it. My $.02.

[TheJuiceman]

Well, here's the deal...
The progs are wanting to be able to su in as a user to check out application settings, etc. But of course I do not want them to be able to su into root, lp, daemon, etc. Also, I do not want them to be able to su into each other's logins (all of the progs have logins that start with a "d"). I really do not want to maintain a list of progs. I also do not want to maintain a list of root equivalents as these can change and leave security holes (an example is we recently started a sql agent on the servers that could be vulnerable with something like this). I don't know if a script can be written that would eliminate anyone with 7** file priveleges, or what. I'm not real sure how to approach that. Also, if I can edit the script to exclude d* logins, that would eliminate su'ing into each other. I am already using sam-r for other things (as well as scm)...some like scm....some like sam better.

[Cheryl Griffin]

Before dismissing sudo as third party, maybe you could reconsider since it is part of a software package provided by HP. See
http://www.software.hp.com/portal/swdepot/displayProductInfo.do?productNumber=HPUXIEXP1111

"Overview
HP-UX Internet Express for HP-UX 11i version 1

HP-UX Internet Express version A.04.00 for HP-UX 11i version 1 contains two sets of components. The first set is a collection of HP-UX Internet Express Open Source Web, Internet, and security components, which have been tested and qualified on HP-UX."

[Mic V.]

Bobby,

It turns out that there is some level of commercial support, third-party (thanks, Cheryl, that's the info I was looking for in another thread):

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

Excellent synopsis of the situation, thanks. Here are some thoughts that may or may not help; I thought I'd speak rather than dragging this out more while I asked questions. :-)

In our setup, the operators (different group than programmers) were responsible for this. Now, this is not ideal, but... When they set up an account, they would use the initial password to log in and verify things. When the user got his account, he was supposed to change the password (didn't always happen, of course, but that's easily fixed). If someone had issues, he gave his password to the programmers, they investigated, and he changed his password (well, supposedly).

If they're not doing problem solving on specific users, perhaps each could have a "play" account to use.

I'm not sure how much administrative red tape your situation will bear or what the interests of your management are (security or not, etc).

If each programmer is responsible for a certain group of users, perhaps you could write a script where each could edit his "responsible" list and the script would make sure they weren't being "bad" (kind of a la sudo). Not my fave security-wise, but...I'm just brainstorming here.

If it's something they "su" in as, that implies it's not a Windows client, I think. Is it the type of thing where you could write a program to interrogate the file(s) that store the application settings for a user? That way, the progs would just run "checkuser smithm" and get the answer.

HTH.