lkml.org 
[lkml]   [2008]   [Nov]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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@linux.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


\
 
 \ /
  Last update: 2008-11-16 17:15    [W:0.051 / U:0.428 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site