On Fri, 13 Apr 2001 wojtek@3miasto.net wrote:

> i would like to add option to disable readability of process info of other
> users completely for non-root (like in linux with secure-linux patch):
> 
> i have almost no experience in kernel programming so is it a good idea to 
> change:
> 
> 	/* only root or same user change look at the environment */
> 	if (type == KERN_PROC_ENV || type == KERN_PROC_NENV) {
>    		if (up->p_ucred->cr_uid != 0) {
> 			if (up->p_cred->p_ruid != p->p_cred->p_ruid ||
> 			    up->p_cred->p_ruid != p->p_cred->p_svuid)
> 				return (EPERM);
> 		}

I realize this is the existing code. But is it me, or is the above logic
test about p_ruid's wrong? If I understand the idea, I should only be able
to see the environment of processes running as me, or su-id processes I
started. That makes a lot of sense.

But the logic test will always return EPERM if p->p_cred->p_ruid !=
p->p_cred->p_svuid since up->p_cred->p_ruid will always be different from
one of them. Thus I, as a non-root user, will only be able to see
processes I started which are NOT set-uid. That's not what I understood
the desire to be.... I think the test should be 

>                       if (up->p_cred->p_ruid != p->p_cred->p_ruid &&
>                           up->p_cred->p_ruid != p->p_cred->p_svuid)

:-)

> to:
> 
> 	/* only root or same user change look at the environment
>            (user_ps_ax!=0) or anything (user_ps_ax==0) */
> 	if (!user_ps_ax || type == KERN_PROC_ENV || type == KERN_PROC_NENV) {
> 		if (up->p_ucred->cr_uid != 0) {
> 			if (up->p_cred->p_ruid != p->p_cred->p_ruid ||
> 			    up->p_cred->p_ruid != p->p_cred->p_svuid)
> 				return (EPERM);
> 		}
> 
> 
> and then lines for sysctl interface (kern.user_ps_ax ?) for user_ps_ax
> variable which defaults to 1 but could be changed to 0.

I think the name "user_ps_ax" is confusing. It's not obvious to me if 0 or
non-zero means that a user can see only her processes. With a default of
1, we get current behavior (which is the least-surprising thing). How
about changing the name to user_ps_ax_all, then 1 means user ps -ax sees
all. Or change the logic and name it no_user_ps_ax (get rid of the !).

> > Maybe depending on the securelevel, i.e. -1, 0, 1, 2, availability of
> > things like top, ps, etc. to non-root should be negated or enabled?
>
> yes. i think that is should be automatic at securelevel >1 but there are
> people that say that it should be selectable behavior.
> any idea other than new sysctl variable?

Ewww.... I think having it an overall default for securelevel > 1 is bad.
I'm the main user of my machine, so it makes a lot of sense for me to be
able to see all of root's processes.

That said, I REALLY understand why we'd want to limit a user to seeing
only his or her processes. I worked at NAS, part of NASA, where we had
different competitors (different aircraft companies) using the same
machines. They really didn't want the competition to see what they were
doing...

So I think something like a sysctl would be good - I can see the advantage
of both choices of a setting. And there's a way to have different sysctl's
set during boot, so an admin could make it so that the machine always
booted multiuser with it set.

> > Why would one do this anyway? the only reasoin I point out the above is it
> > doesn't add a new sysctl variable, and would build upon exisiting ideas if
> > such a thing is needed (which I doubt).  

Oh, it's needed. :-) It's just simultaneously needed and despised. :-) So
something like a sysctl would be good.

The idea of making it something based on login class would be good, but
more work.

Take care,

Bill