| 1 |
On 6 Jun 2006 at 18:44, Kevin F. Quinn wrote: |
| 2 |
> > Clear-Text: http://bugs.gentoo.org/show_bug.cgi?id=134620 |
| 3 |
> > Secure: https://bugs.gentoo.org/show_bug.cgi?id=134620 |
| 4 |
> |
| 5 |
> I was thinking more along the lines of discussing the management of PaX |
| 6 |
> marking in general, with the intention of determining a policy we can |
| 7 |
> apply consistently. Basic options as I see it come down to |
| 8 |
> |
| 9 |
> 1) Have ebuilds set the PaX relaxations that are particular to that app |
| 10 |
> Pros: makes it easy for apps to work on non-MAC PaX systems |
| 11 |
> Cons: user may be unaware of what has been relaxed (creates a "default |
| 12 |
> relax" for affected apps) |
| 13 |
|
| 14 |
imho, this is the only proper solution, any external management is |
| 15 |
misplaced for a simple reason: PaX flags are not a matter of policy |
| 16 |
(not up to an arbitrary human decision), they simply reflect what |
| 17 |
the given application can run with at all. in practice that means |
| 18 |
the need to generate code at runtime (java, skype and others) or |
| 19 |
some assumption about the address space layout (qemu, valgrind, wine, |
| 20 |
etc). in no case should an end user deal with the markings, they |
| 21 |
should (i'd say, must) be dealt with while building the package. |
| 22 |
|
| 23 |
> Further complications come from the variation in PaX DAC markings; vis. |
| 24 |
> chpax vs paxctl, noting also that chpax markings are lost on strip. |
| 25 |
|
| 26 |
i'm trying to get the ELF header extension code to work, so let's |
| 27 |
assume we'll have to deal with paxctl only in the future (in practice |
| 28 |
i think it's mostly java these days that is binary only and doesn't |
| 29 |
have GNU_STACK to convert). |
| 30 |
|
| 31 |
> I did have a go at hooking portage before, but rather overengineered |
| 32 |
> it ;) but here's what I'm thinking now, as an evolution of (2), is to |
| 33 |
> add a QA check to portage, either directly in portage itself or perhaps |
| 34 |
> as a bashrc hook. The check would: |
| 35 |
> |
| 36 |
> a) monitor PaX marking on files as they go to be installed. The swiss |
| 37 |
> army knife that is scanelf helps enormously here, and should make |
| 38 |
> verification quick |
| 39 |
|
| 40 |
imho, the affected ebuilds should explicit set the PaX flags. |
| 41 |
|
| 42 |
> b) by default use a policy file (i.e. list of non-standard executables |
| 43 |
> and PaX markings) distributed with the profiles. This allows for |
| 44 |
> variations according to arch, which may be useful, and makes it easy |
| 45 |
> to maintain and distribute. |
| 46 |
|
| 47 |
no need for this. |
| 48 |
|
| 49 |
> c) forcibly set the PaX relaxations, conditionally on a make.conf var. |
| 50 |
|
| 51 |
yes for forcibly setting it, no for conditionally. |
| 52 |
|
| 53 |
> d) Deal with the chpax strip problem in prepstrip. |
| 54 |
|
| 55 |
no problem as soon as chpax is gone for good. |
| 56 |
|
| 57 |
> I'm not sure there's an ideal hooking point; I would want to be after |
| 58 |
> stripping but before the vdb data is collated. If it has to be before |
| 59 |
> stripping, portage would need to be tweaked to avoid wiping chpax flags |
| 60 |
> in prepstrip (a save/restore should be easy enough). |
| 61 |
|
| 62 |
ideally, the PaX flags would be set from the makefiles (from what i |
| 63 |
recall, some packages build apps that need to be marked that early |
| 64 |
as they are run by the makefile itself). short of that, the ebuilds |
| 65 |
can run paxctl upon installation, before the md5sums are computed. |
| 66 |
|
| 67 |
-- |
| 68 |
gentoo-hardened@g.o mailing list |
Archives