Is there a way by which I can hide my processes from other users if
1) I am the root
2) If i am not the root

Simplest way to "hide" in a legitimate way isn't hiding: it's a form of separation and the GRSecurity kernel patch can supply that (and much more). With the patch applied a process listing only shows users the PIDS they own unless they are allowed an override. Root can hide processes from other users and users can hide processes from other users but of course users can't hide processes from root and root can't hide processes from root. That would be rootkit territory.

I meant surely you have to have UID 0.

Under security through obscurity I meant that when you have insecure find invocation (subject to quickly changing symbolic links in your home directory, for example), exploiting it requires timing. Feasible if you can know exactly when find is started and what it invokes, if at all... Unrealistic if you do not even see it.

If I run shell scripts to process files, you have a good chance to guess what I am doing (from file names, at least, if not from data passed through command-line).

About restricting root logins? Why? If you have a server which has to be protected even from insider attacks (and data loss costs more than data leak which costs more than temporary outage), it is possible to make three administrators to ensure that system is secure, then make them ensure that the only way to login with some rights (including root login) - is through PAM-handled card-reader, and the only two copies of the keys are freshly-generated and reside on these SD cards. Now security forces come, take these SD cards and in presence of all three administrators the most powerful SD cards are closed in special safe that cannot be opened without consent of top executive. To begin with, it is in his room. Companies have already learned to secure high executives' safes. Why three administrators? Because to bribe all three system administrators in exact time is harder than to bribe one and at any time while he is system administrator. Now what you get is that some people who need to have access to half of data stored on server will not know even what processes are run by people who have rights to access the other half. When it is about financial stuff, it can make sense regardless of costs...

... sure it's "possible" - it may even happen It's just the way you talked about it before was just dripping with irony.

I know trading banks that do not do this because it is "too inconvenient". I've seen insurance companies where the server room is locked, but the sysadmin has a terminal for it open on his desk from the time he gets to work... just sitting there... often unattended...

The scenario you describe sounds like the kind of security given to a nuclear arsenal.

... anyway: this brings is back to "why". The "why" question hasn't been answered by OP - you think maybe OP is a top level executive in a financial institution?

... i.e. a specially set up system. But good information anyway.

Sometimes school does minimum security better than a bank. Maybe because bank can not think about worse before it happens, and not know after, and in school you'll always get a new nice boot message once you leave a root terminal unattended.

No. In his case it is at maximum privacy concern and root should simply be trusted. But in general, when we say 'separate users better' it can be also for security. I guess financial is not needed - I think it is not easy to steal too much data on any big company's oncoming new striking product if you work in another research team. If you work on it - sigh...

... i.e. a specially set up system.
Did the OP post that as a requirement? Or does this come from someone who posts "fixes" like "chmod o-x /bin/ps"?

unSpawn: heh heh heh - I don't believe that advanced setup was ruled out. Please do not take that comment as a criticism. And I do not view that (chmod thing) as a "fix" - I view that as a "damage": it just happens to address the specific example - I was hoping it would sound flip.

I think the consensus is: "it's possible but elaborate".
One can use security tricks, or be on an especially installed system, or remove the computer from the network.

The details depend on exactly what one hopes to achieve.

If one would like to configure a network soas to hide processes - then we have our solution. If one wants to hide ones own processes on an arbitrary network - it gets tricky.

Early on I asked for specifics - this is what I meant.
I've also been wondering (on the record) "why" anyone would want to do this. Some speculation has been forthcoming... for which I thank the participants.

Hopefully this thread will be more educational to others stumbling across it than a simple answer would be.

raskin:The way I understood it, the bank had tighter security, but found this made day-to-day administration annoying. The relaxed security was a deliberate decision rather than one based on ignorance.

I don't use internet banking in NZ because basic security steps (like long passwords - one-time passwords etc) are not used. (Though, in this case, customers don't like them...)

Moved: This thread is more suitable in Security and has been moved accordingly to help your thread/question get the exposure it deserves.

Surely they know the rules, but you can never know how much does it cost to violate rules... If you are lucky, it costs nothing.

LIDS also provides functions that can hide a process.

@Simon Bridge: well, I guess that's what I get for not being blunt. What I tried to hint at (being a moderator and all that) is that you basically went and hijacked the thread from the OP and that, if you show to have a limited amount of practical knowledge managing systems (with all due respect), maybe you should not try to categorise other people's answers if you can't assess them properly because "I think the consensus is: "it's possible but elaborate"." clearly is wrong. Anyone (even you ;-p) can set up a GRSecurity-enabled system *without* need for RBAC and *still* containing the separation fixes. (With Gentoo you can for instance since they carry grsec-enabled kernels. Nothing about "trickery" or being elaborate there.) And there you have it...