On Fri, 13 Apr 2001, Bill Studenmund wrote:

> 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.

I suppose the 'more work' reason shouldn'y fly though. If there's
extensive support for login class-related stuff at lower levels, then in
the future, similar problems like this could be solved easier, and of
course, we'd have the continual use of a centralised thing like login
classes to control this.

> 
> Take care,
> 
> Bill
> 
> 


/joseph

--
Joseph Mallett           Security Specialist
jmallett@newgold.net         www.newgold.net

irc.newgold.net/#xMach       xMach Core Team
jmallett@xMach.org             www.xMach.org

xMach Research Group            www.xmrg.com

<josephm> Crystal Pepsi: sure it caused cancer,
          but it was leet.