From: Jacques Gelinas (jack_at_solucorp.qc.ca)
Date: Tue 22 Jan 2002 - 02:49:59 GMT
On Tue, 22 Jan 2002 11:56:24 -0500, edward_at_paradigm4.com.au wrote
> On Monday, 21 January 2002 at 16:11, Jacques Gelinas wrote:
>
> >
> > I agree. I have modified the patch this way
> >
> > if (!capable(CAP_SYS_ADMIN)) return -EPERM;
> >
> > vservers do not have this capability by default and some people may want
> > to do some special jobs in vservers. It sounds a little more general than
> > just relying on the security context.
>
> Yep, it's generic enough and good enough for me but it will
> alter the existing default behaviour of the kernel in context 0
>
> Under stock kernel, non-root users are allowed read access to kernel messages.
> Not necessarily a good thing, if you ask me, but that's a question of whether
> you want to maintain 100% compatibility by default.
>
> How about
>
> if (!capable(CAP_SYS_ADMIN)&¤t->s_context!=0) return -EPERM;
Ok, I buy that :-)
> > I think that /proc is far too complex and too open (any module may add its own trick
> > in it). We would have to review it on a regular basis :-(
>
> Well, any kernel module can do anything it wants to, including overriding
> all syscalls and replacing linux with something else.
> And yes, a badly written module may leave some way to exploit code in kernel space
> via /proc or sysctl. But then again, it may have holes in its other user interfaces
> either.
Yes, my point is that a new module may introduce an entry in /proc and
do a simple suser() test thing to control access to a feature. In most case,
we don't even want to show this to vserver anyway, so with a separate
vproc, we avoid this problem.
> > I want to write a new proc fs called vproc. It would simply be a stripped down
> > proc containing the processes and few other entries in proc. This way, we will
> > have the stuff needed by vservers and this will be enough.
>
> Yes, the lightweight version of proc fs like in BSD is long overdue.
>
> You may also want to look at restricting the sysctl interface.
> I didn't have a chance to go through it yet but it's on the waiting list.
This is done. sysctl is now protected by CAP_SYS_ADMIN. Anyway, check
the patch. You may find something else missing. The cool thing about
peer review and open source :-)
---------------------------------------------------------
Jacques Gelinas <jack_at_solucorp.qc.ca>
vserver: run general purpose virtual servers on one box, full speed!
http://www.solucorp.qc.ca/miscprj/s_context.hc