SOX and user login issue

[Debbie Fleith]

Is there a way to configure a user account in HP-UX 11 so it can be used for file ownership, but NOT be used by anyone as a login?

[Pete Randall]

Sure - don't tell anyone the password.


Pete

[spex]

Hi Debbie,

Create the user in the normal way, and then change his/her login shell in /etc/passwd to '/usr/bin/false'.

PCS

[spex]

Forgot to mention that you need to add '/usr/bin/false' to /etc/shells if it's not already there.

PCS

[Debbie Fleith]

We still need to have user's "su" to this user, so we would need to have a known password setup. Would changing the shell still allow a user to su to the user and use the system? (An audit trail would exist this way and pass the SOX audit, I think)

[Marvin Strong]

You cannot su to an account with /usr/bin/false as the shell because the account would not have a valid shell to use.

[spex]

Debbie,

IANAL. Having said that, changing the login shell to '/usr/bin/false' will also prevent su attempts. On one of my systems, when I try to su to a user with login shell /usr/bin/false, I get:

su: No shell
Bus error

For what you want to accomplish, add something like the following to his/her ~/.profile:

if [ "$(whoami)x" = "$(who am i | cut -f1 -d' ')x" ]; then
exit
fi

'whoami' returns current (post-su) user, while 'who am i' returns the original (pre-su) user, so you can compare their output. If it's the same, you know su wasn't used, so you kill the session.

Consequentially, if the user you want to prevent direct logins for is root,

# echo console >> /etc/securetty

will prevent root from logging anywhere except for the system console, but will still allow su.

PCS

[Marvin Strong]

Well one complex way to do it would be with the use of sudo.

setup an account that noone knows the password for.

setup sudo for the users that need to su to that account. so they can su - account

sudo uses the users passwd and not the password of the account you are suing to.

sudo would also create a log entry for those using the account.

[OldSchool]

Could you possibly base access around the group permissions instead of user perms?

If so, you could create a new group in /etc/group. That group would list the id's of all users who are allowed to work with the files in question. No id in /etc/passwd should default to the new group.

directories would have permissions like 070 and files 010 thru 070 (no user or other perms) perhaps?

[Steven E. Protter]

Shalom Debbie,

I think you may be missing the point of SOX. What you've asked for is impossible, making Pete's answer the 10 point response.

SOX wants an audit trail so that if something bad happens that effects the company it can be traced.

You must have wtmp and btmp files for example.

You must keep logs that are relavent.

Some people think you need shadow passwords but thats not true we passed SOX audits without.

Some people think NIS doesn't comply.

I think the audit trail of a trusted system with audit logs being archived exceeds SOX requirements.

Another thing to watch for. SOX audits often are done with the idea of selling consulting services to help "fix" the problem. Its unethical but I've heard second reports of it happening.

There is nothing wrong with failing a SOX audit so long as you correct the problems in a reasonable period of time. But if you bring in someone to help you prepare for a SOX audit then its buyer beware, they may not have your best interests at heart.

In case anyone asks, we have to comply with SOX on a limited basis because I work for News Corp, through a few levels of Corporate ownerhip and thats a US based/resident(don't remember the term) company.

SEP
Jerusalem
Israel

Things will get calmer here. Trust me.

[Dave La Mar]

Debbie -
This is how we satisfied SOX compliance (at least as far as the auditors were concerned) in our shop.
We:
1. Moved su to another name.
2. Created a wrapper script called su that calls the moved renamed real su.
3. The wrapper script records who performed the su and captures their key stokes into a file while they were su'd as the user.
4. The captured su user file is mailed,daily, to the user and IT middle management with a notice for the user to explain their activity.
5. The log file created cannot be changed by the user that performed the su.

This is a bit involved for all the pieces we use, but I hope you get the gist of this.
Incidentally, the users referred to are developers and their .profile takes them to a menu where they can su or exit [trapping ^C, etc. of course].
Thus the requirement of restricting acces to production code was satifactory to the auditors.

Best of luck on this.

Regards,

-dl

[Arturo Galbiati]

Hi,
you could setup teh account as a ftponly account. In this way user could use it to exchange file but without log in into.
Use /usr/bin/false shell to obtain this.
See this thread for reference:
http://forums1.itrc.hp.com/service/forums/questionanswer.do?threadId=995515&admit=-682735245+1138356176925+28353475

Instead if you want to track the activities of teh suer you could install powerbroker tool.
HTH,
Art

[Debbie Fleith]

Anyone know if SOX rules allow "su" to another login? We want to keep a generic login setup as the owner of a database app and scripts, and anytime we need to admin the db, we would need to "su" to that generic login. I can't disable the shell, but if I follow the suggestions to allow "su" but not an actual login, will it be in SOX compliance?

[Dave La Mar]

Debbie -
What you ask in your last reply is exactly what I was attempting to describe in what we did to be sox compliant.
The generic user in our shop can only be accessed via su and the user performing the su gets all keystrokes recorded for an audit trail.
This was satisfactory to the D & T audit team for SOX compliance.

Regards,

-dl

[Marvin Strong · Accepted solution]

From my understanding of SOX, it is only for creating an audit trail. So that it can be traced encase something happens.

So su is allowed as long as it is traceable.

[A. Clay Stephenson]

One of the things that you will learn is that there are no SOX rules. SOX audits would be much easier if only there were some guidelines as clear as baseball's infield fly rule (and I'm being serious because the infield fly rule has some built-in fuzziness but nothing as fuzzy as SOX). If you actually look at the act itself, computers and IT-related sections are very nebulous. Therefore what is acceptable to one auditor may not be acceptable to another. Su'ing or sudo'ing to another user is neither explicitly allowed or disallowed; but, in general (and for what it's worth), as long as these transitions are automatically logged and can be shown to automatically log then you should be
given an "okey-dokey".

[Debbie Fleith]

Thanks for all the info. Debbie