Boston Linux & Unix (BLU) Home | Calendar | Mail Lists | List Archives | Desktop SIG | Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings
Linux Cafe | Meeting Notes | Blog | Linux Links | Bling | About BLU

BLU Discuss list archive


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Problems loading custom-compiled kernel via Grub



You should check grsecurity.. It protects against that.  I also use the ACL features, and while its possible that somebodies going to get in, they're going to have to try pretty hard, and definately wont be a script kiddie.

CONFIG_GRKERNSEC_KMEM
  If you say Y here, /dev/kmem and /dev/mem won't be allowed to
  be written to via mmap or otherwise to modify the running kernel.
  /dev/port will also not be allowed to be opened. If you have module
  support disabled, enabling this will close up four ways that are
  currently used  to insert malicious code into the running kernel.
  Even with all these features enabled, we still highly recommend that
  you use the ACL system, as it is still possible for an attacker to
  modify the running kernel through privileged I/O granted by ioperm/iopl.
  If you are not using XFree86, you may be able to stop this additional
  case by enabling the 'Disable privileged I/O' option. Though nothing
  legitimately writes to /dev/kmem, XFree86 does need to write to /dev/mem,
  but only to video memory, which is the only writing we allow in this
  case.  If /dev/kmem or /dev/mem are mmaped without PROT_WRITE, they will
  not be allowed to mprotect it with PROT_WRITE later.
  Enabling this feature could make certain apps like VMWare stop working,
  as they need to write to other locations in /dev/mem.
  There are a few video cards that require write access to the BIOS,
  one of which is the Savage.  If you have this video card, you must say
  N here, or Xfree86 will not function.
  It is highly recommended that you say Y here if you meet all the
  conditions above.


On Wed, Dec 31, 2003 at 04:32:20PM -0500, gboyce at badbelly.com wrote:
> Not enabling module support doesn't help security.  You can achieve the 
> same effect by patching /dev/kmem directly, and there are root kits that 
> make this script kiddy ready.
> 
> On Wed, 31 Dec 2003, miah wrote:
> 
> > I really dislike initrd for this reason.  Which is why my policy is to make things the kernel needs to boot part of the kernel, and other modular.  Of course, I generally don't enable module support at all, especially on server systems due to security concerns.
> > 
> > -miah
> > 
> > On Wed, Dec 31, 2003 at 12:04:53PM -0500, Don Levey wrote:
> > > 
> > > 
> > > Gregory Boyce wrote:
> > > > If you get the same error while specifying root=/dev/sda1, then perhaps
> > > > the kernel does not have the ability to read your root file system for
> > > > some reason.
> > > 
> > > That might be the case.  In any event, I decided to start over.  This is all
> > > in VMWare images right now, so that's easier than it could be.
> > > 
> > > > Is SCSI support compiled into the kernel, or is it a loadable module?
> > > > What about support for the filesystem type? (ext3?)
> > > 
> > > As I'll rebuild this test kernel today, I can ensure that I enable both as
> > > part of the kernel.
> > > 
> > > > Using them as modules can work, but only if the initrd loads those
> > > > modules.  If you made it using Redhat's mkinitrd, I believe you need to
> > > > specify which modules should be autoloaded.
> > > 
> > > > On Tue, 2003-12-30 at 18:49, Don Levey wrote:
> > > >> I actually tried something similar - root=/dev/sda1
> > > >> which is my / partition (no separate /boot).
> > > >> I got a similar error, this time referencing /dev/sda1 instead of
> > > LABEL=/.
> > > >> I may be able to try Dan Barrett's suggestion about the stripped-down
> > > config
> > > >> file.
> > > >>  -Don
> > > >
> > > 
> > > I also redid my wife's kernel last night, to take advantage of support for
> > > the onboard NIC (Broadcomm 4400), better support for the sound card (Intel
> > > i810), and ACPI support.  She's on a Dell Inspiron 1100 laptop.  It went
> > > well, mostly.  I'm having difficulties with USB support, the NIC module
> > > doesn't get built  (though it's specified in the .config and I don't get an
> > > error), and the consoleis a small screen even though I've got vga=773 in the
> > > grub.conf.  X is fine, and full screen.  But I did get the wireless card to
> > > work via the DriverLoader at linuxant.com, so we're getting somewhere.  I'll
> > > be trying the new kernel build at work today.
> > > 
> > > Thanks again,
> > >  -Don
> > > 
> > > _______________________________________________
> > > Discuss mailing list
> > > Discuss at blu.org
> > > http://www.blu.org/mailman/listinfo/discuss
> > _______________________________________________
> > Discuss mailing list
> > Discuss at blu.org
> > http://www.blu.org/mailman/listinfo/discuss
> > 
> 
> _______________________________________________
> Discuss mailing list
> Discuss at blu.org
> http://www.blu.org/mailman/listinfo/discuss




BLU is a member of BostonUserGroups
BLU is a member of BostonUserGroups
We also thank MIT for the use of their facilities.

Valid HTML 4.01! Valid CSS!



Boston Linux & Unix / webmaster@blu.org