Announcing security hardened kernels for testing

[Mike Hearn]

On Thu, 2005-01-06 at 02:28 +0100, pageexec at freemail.hu wrote:
> for historical reasons, there're 2 marks. the older one (controlled by
> chpax) abuses an otherwise (or yet) unused field in the ELF header, i
> personally don't encourage the use of it. the other one (controlled by
> paxctl) is based on a new ELF program header type called PT_PAX_FLAGS
> and requires a binutils patch (being specific to PaX and in direct
> conflict with PT_GNU_STACK, it has about 0 chance to end up upstream).

Hmm, OK. If you think PaX may be deployed in a mainstream distribution
like Ubuntu by default being able to build with this marking is
something we should remember.

> my problem wasn't that you reserved all address space 'upstairs', but
> that the algo wine has can end up in an infinite loop (requesting kernel
> space memory is another thing, but given how non-existant is a decent
> API for learning about the address space layout in linux, i won't blame
> this on you ;-).

Yeah, scraping /proc/self files is silly but unfortunately quite common
on Linux ... I'd love a decent VirtualQuery type API for other non-Wine
stuff I've done if nothing else.

> interestingly, i also have this need to have some control over the
> address space and have a plan to do this eventually. the idea is to
> introduce a new ELF program header (because this is the easiest to parse
> at execve() time in the kernel), that would describe the desired
> TASK_SIZE, stack placement and other info you might need. how something
> like this would fly with upstream (both binutils and the kernel),
> i can't tell however.

That would be good. My last experience with this sort of patch was
trying to fix a bug in the kernel ELF loader though. John Reiser
developed a patch which fixed the bug but it didn't compile on some
architecture he didn't have access to and was dropped.

> you're right with the behaviour of MAP_FIXED, but then i still think
> that something is wrong with the allocation algo if it can loop forever
> (or i wasn't patient enough).

That's something for Alexandre to comment on, I didn't write that code
and never really looked at it.

> if you need more info, feel free to ask. for your particular question,
> it's always been about the compiler detecting the use of nested function
> trampolines (never inline asm and other ways of runtime code generation)
> and the linker erring on the side of backwards compatibility.

OK. For your other email I think it'd be better to use the gas pseudo-op
to add the .note.GNU-stack, that way we don't need configure checks for
the ld flags.

> ok, this is the really interesting part for me, so let's discuss it a bit
> more.
> 
> > a) Used by some Windows programs
> 
> this is fine and can't be helped of course. my hope is that most apps, or
> rather, the ones i'm personally interested in don't generate code runtime.
> 
> > b) Used by the Wine DLL loader
> 
> what is this use exactly? can it be reworked to not require runtime code
> generation (remember that i'm willing to scratch my own itch, i just need
> some pointers)?

Alexandre recently added a patch to generate DLL stubs at runtime as
part of the process of removing them from the compile-time generated
code. I think it's also used for +relay traces (where each API call is
dumped as it's called). 

Obviously +relay is only used in debugging so Wine could run without
that. The stub block thing is a bit trickier, that patch could be
reversed and Wine would still run correctly because we still generate
stubs at compile-time too (iirc), but it's part of a policy of
eliminating unnecessary stubs over time. So I'm not sure Alexandre would
want to remove it.

> > c) Required to implement DCOM universal interface proxies
> 
> required as in 'cannot be implemented any other way'? 

I'm not sure. These proxies are run-time generated objects. Essentially
a DCOM universal/typelib marshaller proxy is a COM interface (so an
array of function pointers) that when called marshal the arguments into
a packet and dispatch it via the Windows RPC infrastructure. These
proxies come in three forms:

- precompiled MIDL/C marshallers
- precompiled MOPs (these are a custom bytecode language fed to a VM
  which does the marshalling)
- generated at runtime from type libraries (databases which describe
  the types and interfaces used in a program)

I don't know if the second needs runtime code geneation but I don't see
any way we can avoid generating code for the third at runtime.

> and same question
> as above of course. also, this feature doesn't sound like something that
> all windows apps need, 

I'm afraid InstallShield needs it, and InstallShield is a "gateway" app,
ie if it doesn't run lots of other programs also don't run (because you
can't install them).

> so i wouldn't have a problem with allowing it (note
> that i'm talking about PaX based systems only, not wine in general, so no
> worries about me trying to force something on you) if i can run the rest
> of the apps with full PaX enabled.

Yes the trick is, how do you know when it's needed or not? I'm not sure.

> i've never sad it wasn't legitimate, just that it's a privilege and if we
> want protection from exploits, then we'd better revoke it from apps that
> don't need it (and which get it by default and cause security problems).

OK this opinion is fair enough, if a little unusual.

> obviously my goal is to run as many apps as possible without this privilege
> (especially those that process untrusted user input, be that server daemons
> or client apps like mail clients, web browsers, etc). if there're fundamental
> reasons why wine cannot work without such a privilege, then so be it, it'll
> go the way of java on PaX systems and be exempted.

I think some programs could run on a hacked and Wine but the problem is
when InstallShield fails in a mysterious way how do you know it's PaX
and not some other problem? I don't see how to communicate that to the
user in a useful manner ...

> > They have to be fixed otherwise the kernel may place them in the middle
> > of a reserved area which would cause initialisation to fail. This cannot
> > be changed.
> 
> i meant something like a new switch to configure that would let you specify
> a new compile/link time base address, that can surely be arranged...

Ah yes that could work though you'd have to test the resulting binaries
to ensure there were no conflicts (the reserved regions are stored in a
table).

> there's already such support in the binutils patch i mentioned above:
> 'ld -z execheap/-z noexecheap' (you'd use the former to mark the preloader
> which in turn would allow runtime code generation). post linking, you
> can use 'paxctl -spmr' (or the deprecated chpax) to disable all non-exec
> enforcement and randomization. but as i suggested at the beginning, this
> should not be your concern but that of the distro guys (and pending the
> questions i raised, it may very well turn out to be unnecessary, at least
> i'll try my best to make it happen).

OK, thanks for the feedback. I have to admit I'm not keen on leaving
much up to the distribution guys, in the past they've typically shown
little to no concern about keeping Wine working (probably because due to
our ridiculously fast release cycle we're never shipped as part of their
base sets).

thanks -mike