Message-ID: <20081116171139.0456b1b2@kopernikus.site>
Date:	Sun, 16 Nov 2008 17:11:39 +0100
From:	Bernhard Walle <bwalle@...e.de>
To:	Alan Cox <alan@...rguk.ukuu.org.uk>
Cc:	x86@...nel.org, linux-kernel@...r.kernel.org,
	linux-arch@...r.kernel.org, crash-utility@...hat.com
Subject: Re: Turn CONFIG_STRICT_DEVMEM in sysctl dev.mem.restricted

* Alan Cox [2008-11-16 15:45]:
>
> > I don't need to explain what protection STRICT_DEVMEM provides, just
> > because I didn't submit STRICT_DEVMEM. However:
> 
> Which also doesn't explain what this turd is for.

Could we discuss more factual without words like "turd", please?

> >     Author: Arjan van de Ven <arjan@...ux.intel.com>
> >     Date:   Thu Apr 24 23:40:47 2008 +0200
> > 
> >     The X server needs access to /dev/mem for the PCI space, but it doesn't need
> >     access to memory; both the file permissions and SELinux permissions of /dev/mem
> >     just make X effectively super-super powerful. With the exception of the
> >     BIOS area, there's just no valid app that uses /dev/mem on actual memory.
> 
> Note that this statement directly conflicts with your debugging statement
> you need it switchable, and directly conflicts with the Red Hat crash
> memory access. So you are trying to support something with a changelog
> that demonstrates that what you are trying to make configurable is
> completely broken anyway
> 
> The functionality provided by STRICT_DEVMEM is the same with it on or off
> - absolutely *nothing*.

Even with SELinux?

> You can turn it off at boot time, but if you intend not to use it then it
> is better (and measurably so with microbenchmark tools) to compile
> without it. Red Hat doesn't do the two kernels as the maintenance cost
> exceeds the gain for customers.

And that's the same argument why SUSE does not ship a -devmem and a
-nodevmem kernel. When you turn it off, you lose the protection that is
there if you use SELinux / Apparmor. If you turn it on, you cannot use
crash.

 Note however that compiling it out really
> does compile it *out* and the overhead is gone totally for the many
> embedded and other devices that don't use it.

For SELinux, yes. 

> > But I never used it. At least I don't see -selinux and -noselinux
> > kernels in Redhat.
> 
> It is Red Hat, two words and a trademark (sorry but our legal people
> insist we remind people who get it wrong).

Oh well, I don't tell it our legal people if you would write SuSE
instead of SUSE. Even not S.u.S.E. ;-)

> > However, with my patch you can make everything configurable. With
> > SELinux or Apparmor you can also protect the user from writing that
> > sysctl. Or from loading kernel modules that circumvent that protection.
> 
> With your patch I get crap in the kernel I don't need. In every kernel
> including those on memory tight devices like wireless routers that don't
> need it.

Well, if you let the CONFIG option there and only add the sysfs entry
it does not. Even most embedded stuff is not x86.

> Even if you want to turd polish there are cleaner solutions. A process
> with CAP_SYS_RAWIO can cheerfully bypass any restriction you try and
> place so you could rip out all the sysctl crap and just say that
> the /dev/mem restriction doesn't apply to a CAP_SYS_RAWIO process.

According to Arjan that does not work.


Regards,
Bernhard
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists