[Top][All Lists]

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

[Tinycc-devel] Re: lib/alloca*: mark ELF stack access flags as nonexecut

From: grischka
Subject: [Tinycc-devel] Re: lib/alloca*: mark ELF stack access flags as nonexecutable
Date: Thu, 06 Jan 2011 22:03:31 +0100
User-agent: Thunderbird (Windows/20090812)

Sergei Trofimovich wrote:
How does tcc violate that stack policy?
It always generates execstack binaries (not fixed yet).

$ ./main.tcc Killed
PAX: terminating task: /tmp/z/main.tcc(main.tcc):17706, uid/euid: 1000/1000, 
PC: 0000719781b5175f, SP: 0000719781b51748
However that would mean that tcc does NOT generate execstack binaries.
(Unless the reason for the crash is something else.)

It does, but PAX kernel (a set of patches on top of vanilla kernel
 http://pax.grsecurity.net/docs/) won't allow you to run (or operate
suspiciously) a binary with any static or dynamic mapping of Writable
and eXecutable bits enabled for _any_ vma to exist in kernel.

Are you saying that the PAX kernel refuses to run anything created
by tcc at all?

For example if you will try to workaround page permissions  for mmap/mprotect 
you'll get an
error from syscall.

I've posted 2 results:
    hardened: fail/failone
nonhardened(standard for most users): (fail/run)
Repasting nonhardened results:
On nonhardened box:
$ ./main.gcc
Segmentation fault

[sf] /tmp/z:./main.tcc [sf] /tmp/z: # ooops, needs to be fixed!

Here we see execstack is on in tcc generated binary and off on gcc's one.

Well, tcc simply does not specify executable permissions for the stack
so it's neither "off" nor "on" really.

It is just that I have some doubts about a policy which has execstack
"on" by default in the system but then wants everybody to add ugly hacks
into applications to fix this.

But maybe that's just me.  Anyway, thanks for the info and links etc.

--- grischka

reply via email to

[Prev in Thread] Current Thread [Next in Thread]