restrict ps -f

[Rushank]

Hello,

Is there a way to restrict users to execute ps with -f option?
If user knows the ps -f command then UNIX95 is not an option here.

Any other ideas..?

[Pete Randall]

First you could change the permissions on it - that would make it unavailable to anyone but root. Second you could put a bogus alias in their profile and try to take away their ability to update said profile.

Why?

Pete

[Tom Geudens]

Hi,
You could "alias" it ... take a look at "man alias". Lot's of options there ...

Hope this helps,
Tom

[Rushank]

Thanks for your thoughts,
user can change his .profile file and alias is not going to work here, users are smart , they can run unalias and they know how to make use of ps -ef command.

Changing permission of ps also not going to work because they need to know pid , ppid and other information for the debug. I want to restrict just the command line (format)

[Pete Randall]

Well, I guess I'm at a loss then - but I'm still curious why you would need/want to restrict this.

Pete

[Pete Randall]

Actually, I do have one other thought -

Replace /usr/bin/ps with a script of the same name that will check the user id and then restrict options accordingly before invoking the real ps command which you will have hidden away where they can't find it.

Pete

[Dietmar Konermann]

Just some additional thoughts...

Actually there is no way to do this restriction when talking about smart users.

ps(1) uses the pstat() syscall and this syscall is nearly unrestricted. One could write his own ps or, even more simple, bring in an own copy of a ps executable.

To restrict "not so smart" users I would replace ps by a shell script handling the access... but be careful not to break non-root application that need ps!

Regards...
Dietmar.

[Rushank]

There are some sql and other legacy scripts passes username and password in pure ascii character, and when a user runs ps -f command they can actually see the passwords
This is the reason I want to restrict the -f option.

[Rushank]

any other ideas???

[Pete Randall]

Physically remove the "f" key from their keyboards?

Just kidding -

;^)

Pete

[Dietmar Konermann]

If you really want to protect the passwords then you need to change the legacy scripts not to pass them on the comannd line. The command line is not protected... that's it.

[Rushank]

Yes that was my initial thought , but then we have hundreds of scripts.!

[harry d brown jr]

Yes, KEEP your users out of SHELL 's!


There is NO valid reason to have USERS in a SHELL. PERIOD. EXCLAMATION POINT(S).

If you want to keep users from seeing passwords because some LAME process requires passwords to be passed to it on the command line, then FIX the application. FIXING the PROBLEM is the cure to the disease.


live free or die
harry

[Rory R Hammond]

Many years ago, when I had a source code license. I modified ps so that it would not return information on certain UID's. Faking the average users because the options worked on all of the other "stuff". But this is just a band aid and false security at best.

I understand that you have lots of scripts, but they truly need to be changed. Your system is very exposed. You have to much risk for intrusion. The statement of "having to many scripts" would not go far with Management trying to asses blame.

I haven't looked at the latest sudo program. But I have a modified version that allows "special" users to execute certain programs using various service ID's without a password. IE Oracle, Informix, etc.. This has method works very well me.

I admit that I do have a few Oracle scripts that uses a scott/tiger password that can be ps'd, But scott only has read authority for certain tables, of which We don't care if anyone sees and scott Does not have a unix login.

Good luck
Ror