| 1 |
On 19 Sep 2015 at 22:40, Alex Efros wrote: |
| 2 |
|
| 3 |
> Hi! |
| 4 |
> |
| 5 |
> On Sat, Sep 19, 2015 at 09:33:15PM +0200, PaX Team wrote: |
| 6 |
> > > > 1. enable ELFRELOCS in your kernel config (and keep MPROTECT enforced |
| 7 |
> > > > on all binaries) |
| 8 |
> > > Done. This works. I don't really like it, but let it be, at least for now. |
| 9 |
> > well, disabling MPROTECT is much worse, this way you can at least |
| 10 |
> > control which binaries can map libaries with textrels. |
| 11 |
> |
| 12 |
> I don't get it. With MPROTECT I control which binaries won't be protected. |
| 13 |
|
| 14 |
not quite ;). for MPROTECT to be effective you also need to control what |
| 15 |
the application can do to the filesystem (in particular you have to prevent |
| 16 |
anything equivalent to the sequence of open/write/mmap). this requires the |
| 17 |
use of some access control system that PaX itself lacks (by design). in |
| 18 |
grsecurity's case it's the RBAC system with a proper policy. if you're not |
| 19 |
doing this part then MPROTECT doesn't provide you the guarantees over runtime |
| 20 |
codegen. |
| 21 |
|
| 22 |
> With ELFRELOCS I don't control binaries and all of them will be less protected. |
| 23 |
> And I doubt "all less protected" is better than "few not protected". |
| 24 |
|
| 25 |
based on the above explanation now you can probably see that once you have |
| 26 |
RBAC (or equivalent) in place then that same mechanism can also be used to |
| 27 |
control which apps can load textrel libs which is how you win twice: |
| 28 |
|
| 29 |
1. MPROTECT can be enforced on everything (or at least no need to relax |
| 30 |
it because of textrels) |
| 31 |
2. only specifically allowed apps can punch a controlled hole into MPROTECT. |
Archives