re: /proc/kmsg

About this list Date view Thread view Subject view Author view Attachment view

From: Jacques Gelinas (
Date: Mon Jan 21 2002 - 21:49:59 EST

On Tue, 22 Jan 2002 11:56:24 -0500, 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)&&current->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 <>
vserver: run general purpose virtual servers on one box, full speed!

About this list Date view Thread view Subject view Author view Attachment view

This archive was generated by hypermail 2.1.4 : Mon Aug 19 2002 - 12:01:00 EDT