Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Fri, 29 Jul 2011 22:06:14 +0400
From: Vasiliy Kulikov <segoon@...nwall.com>
To: kernel-hardening@...ts.openwall.com
Subject: Re: -ow features

Solar,

On Fri, Jul 29, 2011 at 21:30 +0400, Solar Designer wrote:
> > HARDEN_VM86
> > 
> > The code similar to -ow patch is ready, but I don't know how it should
> > be implemented relative to LSM/seccomp/etc.  It looks like a small
> > feature, which is not consistent with current upstream security
> > architecture.  I've described the problem here:
> > 
> > http://www.openwall.com/lists/kernel-hardening/2011/06/19/2
> > 
> > Without the major change of the configuration mechanism it's impossible
> > to get it applied.
> 
> In -ow, there's also CONFIG_BINFMT_ELF_AOUT.  When it is not enabled -
> and by default it is not - uselib(2) is disabled (returns -ENOSYS) and
> parts of binfmt_elf.c responsible for loading a.out libraries for ELF
> binaries are also disabled (truly ancient stuff).  We need something
> like this for 3.x and RHEL6 kernels too.
> 
> Maybe the CONFIG_BINFMT_ELF_AOUT option may be accepted upstream on the
> grounds that it's similar to other CONFIG_BINFMT_* options?

Do you propose to move all ELF_AOUT code to a configurable option, just
like STRICT_DEVMEM?  Looks like a good plan - kernel developers don't
like to support legacy stuff.  If it is moved to a config option, then
in some years it could be even fully removed (if I understand the AOUT
significance).

-- 
Vasiliy

Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.