l i n u x - u s e r s - g r o u p - o f - d a v i s
Next Meeting:
July 7: Social gathering
Next Installfest:
Latest News:
Jun. 14: June LUGOD meeting cancelled
Page last updated:
2008 Aug 22 06:36

The following is an archive of a post made to our 'vox-tech mailing list' by one of its subscribers.

Report this post as spam:

(Enter your email address)
Re: [vox-tech] Linux file/module security proposal.
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [vox-tech] Linux file/module security proposal.

Wes Hardaker wrote:
>>>>>> On Thu, 21 Aug 2008 10:16:03 -0700, Bill Broadley <bill@cse.ucdavis.edu> said:
>>> Well, it all comes down to how much of the system the hacker owns.  If
>>> he has root on your machine he's likely inserted a kernel module to hide
>>> things or change things 
> BB> Right, but if the kernel only accepts signed binaries then he can't.
> Ah, yes...  I agree.  I even know it's been done.  The problem is that
> it's not generally deployed :-(

Yup, and I'm trying to lower the barrier to entry.

> You need:
>   - A kernel that only accepts signed modules

Yup, this is standard with fedora or redhat for the last few years, you just 
need a boot parameter.

>   - A system that protects the file system where kernel components and
>     keys are installed (or else all it takes is a reboot)

Agreed, a short howto on how to set bios and prepare media for booting (PXE, 
cdrom, usb key, or an external driver with a RO switch)

>   - A system that protects the memory

Yup, /dev/kmem, /dev/mem and friends need protected, I think that's default 
these days, might need a tweak or two, it's been implemented with selinux, 
seclvl, er, I think grsecurity and a few others.

Does your distro/kernel allow writing to memory?

> So, all of those have been done.  SELinux brings a lot of it to the
> table that is needed, in fact, and I know there has been a lot of work
> to ensure kernels only load signed modules.

The most popular project seems to be MODSIGN:
> Unfortunately, I don't think most people have half of what they need
> turned on in order to accomplish the above.

Well it all helps.  A mirror and a short howto would lower the bar 
significantly.  For instance even if a compromise required a reboot, at least 
that's better and more noticeable than not.

> (I know I'm sounding pessimistic...  In part because I've looked at
> doing something like this before.  It's a lot of work when you get down
> to the nitty-gritty.  You're right, though, that it should be possible
> in theory.)

Well MODSIGN, a working mirror, selinux, and DigSIG are almost all of the 
pieces except the documentation.  Sure small tweaks would improve things 
further, but I think it's a rather beneficial increase in security as is. 
Especially since many of the changes to improve it are trivial enough that I 
suspect a bit more exposure would lead to someone submitting a patch.  CDR 
already has me processing each RPM/DEB file to extract the checksums, running 
bsign on the binaries would be trivial.

> Personally, I think it might be easier to do only-loading-of-modules
> from R/O media that are created on a different system and have the key
> systems all boot from CDROM or something.  That way you don't need to
> worry quite as much about all the security policies being written perfectly.

Not sure how you could prevent future loading of modules, or require loading 
only from RO media.  I'd actually kinda like booting from USB, it would be 
especially idea if you use an encrypted filesystem and kept the key on the usb 
vox-tech mailing list

LUGOD Group on LinkedIn
Sign up for LUGOD event announcements
Your email address:
LUGOD Group on Facebook
'Like' LUGOD on Facebook:

Hosting provided by:
Sunset Systems
Sunset Systems offers preconfigured Linux systems, remote system administration and custom software development.

LUGOD: Linux Users' Group of Davis
PO Box 2082, Davis, CA 95617
Contact Us

LUGOD is a 501(c)7 non-profit organization
based in Davis, California
and serving the Sacramento area.
"Linux" is a trademark of Linus Torvalds.

Sponsored in part by:
Appahost Applications
For a significant contribution towards our projector, and a generous donation to allow us to continue meeting at the Davis Library.