# How to see all processes with a non root user

## jeromeBis

Hi,

I have 2 Linux servers.

One with Debian 4.0 and the other with Gentoo Base System release 1.12.11.1.

On the Debian with a non root user who is not in the root group I can see all the process, even the root ones.

On the Gentoo, I can only see my process.

For your information, I'm using "ps -leaf" or "ps aux" to check that.

Thanks in advance for your answers,

Regards,

Jerome

----------

## NeddySeagoon

jeromeBis,

Welcome to Gentoo

Thats a feature of gentoo-hardened, to allow users to see only processes they own.

No users anywhere on any distro should be in the root group ever. Thats the same as being root all the time.

If you need root sometimes, look at sudo.

----------

## jeromeBis

Hi,

OK, but how can I change that to allow one non-root user to see all process running?

I just want to have a non-root "superviser" who can only check what is going on the server.

Thx

----------

## NeddySeagoon

jeromeBis,

Install sudo and configure it to allow this one user to use the commands you want the superviser to be able to run as root.

The syntax then becomes 

```
sudo <command>
```

If command is in the permitted list, it runs as root, if not sudo sends root an email.

The superviser has to give his user password the first time sudo is invoked but for a sequence of commands, its not needed every time.

I think the default timeout is about five minutes. Anyway, its long enough not to be annoying.

----------

## jeromeBis

NeddySeagoon,

I know the "sudo" command, but I would prefer to call directly the "ps" one because I need to automate a check of the process.

Thx,

Jerome

----------

## NeddySeagoon

jeromeBis,

I'm out of ideas.  Make a special user that cannot log in to run the script as comes to mind but that sounds ugly

----------

## Jaglover

How about configuring sudo to allow this command without password [for this user].

----------

## Akkara

Allowing sudo to work without password sounds risky.

I think a modification on Neddy's idea might work: Write a program that simply calls the main 'ps'.  Put it in /usr/local/bin, and make sure /usr/local/bin appears first in your regular user path.  So when you run 'ps', is runs /usr/local/bin/ps, which execs /bin/ps.  (and when root runs ps, root picks up the /bin/ps version directly since /usr/local/bin isn't in root's path.)

Next, make a new user, one that can't log in.   Put the new user in the 'root' group.  Make /usr/local/bin/ps setuid owned by this new user.  

If I understand correctly (I didn't test this), the /usr/local/bin/ps version ought to be able to see all processes even though you aren't running as root.

If you want to restrict access to just one specific user, you can either have the program check the real user before exec'ing, or stick it in a subdirectory that's only readable by the user you wish to allow.  (And make sure it isn't writable, so that user can't remove the binary and put a different one in there.)

----------

## jeromeBis

Thanks Jaglover,

I've added:

```
jerome          ALL=(ps) NOPASSWD: ALL
```

to the /etc/sudoers (via visudo) and it works great.

I don't like (esthetically speaking) using "sudo" in the commands but it does the work.

Thanks again,

Regards,

Jerome

----------

## XQYZ

 *jeromeBis wrote:*   

> Thanks Jaglover,
> 
> I've added:
> 
> ```
> ...

 

Either add an 'alias ps="sudo ps"' to the users bashrc or add a script named "ps" in the path of the users before the actual ps-path which then calles the real ps with sudo. Poth should work.

----------

## wthrowe

The details of the restrictions are controlled by the GRKERNSEC_PROC* kernel configuration options.  I don't know how those configurations work, but it looks like the kernel can restrict access to a single group, which might be a better solution.

----------

## jeromeBis

Wrong line, here is the good one:

```
jerome          ALL=(ALL) NOPASSWD: /bin/ps
```

----------

## Jaglover

 :Smile:  Glad you got it working the way you want.

----------

## Mike Hunt

Huh, how come mine can do that?

I get the exact same output from ps -leaf and ps aux as both <user> and root 

```
 ~ # ps aux | wc -l; ps -leaf | wc -l

128

128

 ~ $ ps aux | wc -l; ps -leaf | wc -l

128

128
```

My user is GID users and in the wheel group, if that makes a difference. Otherwise everything is a standard installation.

----------

## desultory

 *Mike Hunt wrote:*   

> Huh, how come mine can do that?

 Is it running on a hardened system? If so, what policies are in effect?

If the answer to the first question is "no" or the answer to the second is either "none" or some suitable variation on "permissive", it is the expected behavior.

----------

## jeromeBis

Hi,

How can you see if a system is hardened and how can you change its policies?

----------

## desultory

http://www.gentoo.org/proj/en/hardened/selinux/selinux-handbook.xml?part=3&chap=1

----------

## jeromeBis

It doesn't seem I'm in this case.

"ls -Z" and "ps au -Z" gives nothing particular and I do not have sestatus or policyvers (tried as root).

----------

## Mike Hunt

 *desultory wrote:*   

>  *Mike Hunt wrote:*   Huh, how come mine can do that? Is it running on a hardened system? If so, what policies are in effect?
> 
> If the answer to the first question is "no" or the answer to the second is either "none" or some suitable variation on "permissive", it is the expected behavior.

 

Ah I see, it's regular Gentoo. I misunderstood NeddySeagoon's first answer. 

Thanks for the clarification.  :Smile: 

 *jeromeBis wrote:*   

> Hi,
> 
> How can you see if a system is hardened and how can you change its policies?

 

What does eselect profile show say about the profile? Wouldn't a hardened system use a hardened profile?

And wouldn't you (or someone) have had to enable it explicitly?

----------

## Hu

 *Mike Hunt wrote:*   

> What does eselect profile show say about the profile? Wouldn't a hardened system use a hardened profile?
> 
> And wouldn't you (or someone) have had to enable it explicitly?

 For best results, a hardened profile should be used with a hardened kernel.  However, it is possible to run hardened kernels on a non-hardened profile.  There are specific changes in the hardened kernel that account for the behavior you inquired about, and these changes can be used without a hardened user environment.

A hardened stage3 tarball may start out associated with a hardened profile, in which case the user might be on a hardened profile without having fully realized it.  However, since hardened kernels and hardened profiles are separate, the user would still need to manually choose a set of hardened kernel sources to be on a hardened kernel and experience the cloaking behavior described in this thread.

----------

## jeromeBis

Hi,

Sorry, I've been out for 2 weeks  :Wink: 

Here is the result of "eselect profile show":

```

Current make.profile symlink:

  default/linux/amd64/10.0

```

----------

## phajdan.jr

 *jeromeBis wrote:*   

> 
> 
> OK, but how can I change that to allow one non-root user to see all process running?
> 
> I just want to have a non-root "superviser" who can only check what is going on the server.
> ...

 

I think it may be possible. Check your kernel configuration carefully. Look for grsecurity options.

----------

## cach0rr0

 *jeromeBis wrote:*   

> Hi,
> 
> Sorry, I've been out for 2 weeks 
> 
> Here is the result of "eselect profile show":
> ...

 

aint a hardened profile  :Smile: 

hardened shows as

```

 # eselect profile show

Current make.profile symlink:

  hardened/linux/amd64/10.0

```

check eselect profile list to see available options. If you opt to change to a hardened profile at some point, make sure you sift through the Hardened doc before doing so. It describes how to do this and rebuild your system in detail

----------

## phajdan.jr

The profile is not so relevant here. The process visibility restriction is implemented in the kernel. I bet you're using hardened-sources (you can check with "uname -a" and "eselect kernel list").

----------

## cach0rr0

 *phajdan.jr wrote:*   

> The profile is not so relevant here. The process visibility restriction is implemented in the kernel. I bet you're using hardened-sources (you can check with "uname -a" and "eselect kernel list").

 

no, for sure, i agree, and I'm aware. I remember the menuconfig option quite well in fact, "restrict user access to /proc" or some such. 

I'm going off on a tangent in case he's curious, pay me no mind  :Smile: 

----------

## jeromeBis

Here are the results of the 2 commands:

```
jerome@:~ [09:46:00]$ uname -a

Linux .ovh.net 2.6.32.2-xxxx-grs-ipv4-64 #1 SMP Tue Dec 29 14:41:12 UTC 2009 x86_64 Intel(R) Core(TM)2 Duo CPU E6550 @ 2.33GHz GenuineIntel GNU/Linux

jerome@:~ [09:51:08]$ eselect kernel list

Available kernel symlink targets:

  (none found)

```

----------

## cach0rr0

so, how the deuce did you install your kernel? 

the name isn't one of the hardened-sources variety that i recognize, and the latter command indicates - as you might expect, that there is no symlink named "linux" within /usr/src that points at your kernel sources set.

----------

