| 1 |
On Tue, 6 Jun 2006 17:05:14 +0300 |
| 2 |
Alex Efros <powerman@××××××××××××××××××.com> wrote: |
| 3 |
|
| 4 |
> As kevquinn@g.o says, discussion about this bug probably |
| 5 |
> should be moved into hardened maillist: |
| 6 |
> |
| 7 |
> Clear-Text: http://bugs.gentoo.org/show_bug.cgi?id=134620 |
| 8 |
> Secure: https://bugs.gentoo.org/show_bug.cgi?id=134620 |
| 9 |
|
| 10 |
I was thinking more along the lines of discussing the management of PaX |
| 11 |
marking in general, with the intention of determining a policy we can |
| 12 |
apply consistently. Basic options as I see it come down to |
| 13 |
|
| 14 |
1) Have ebuilds set the PaX relaxations that are particular to that app |
| 15 |
Pros: makes it easy for apps to work on non-MAC PaX systems |
| 16 |
Cons: user may be unaware of what has been relaxed (creates a "default |
| 17 |
relax" for affected apps) |
| 18 |
|
| 19 |
2) Have ebuilds do no such thing, and manage the markings externally. |
| 20 |
This is a kind of poor-man's MAC, in as much as it consists of a central |
| 21 |
file listing everything that might be relaxed. With init.d/chpax this |
| 22 |
is, "enforced" by a start-up script. |
| 23 |
Pros: policy is clear, for the sysadmin |
| 24 |
Cons: we need to maintain the policy file |
| 25 |
if done outside of portage, messes up unmerges |
| 26 |
|
| 27 |
The problem highlighted on the bug is that approach (2) as currently |
| 28 |
implemented by the init.d/chpax script messes the mtime/md5sum of files |
| 29 |
thus causing portage to avoid removing them when packages are unmerged. |
| 30 |
|
| 31 |
Further complications come from the variation in PaX DAC markings; vis. |
| 32 |
chpax vs paxctl, noting also that chpax markings are lost on strip. |
| 33 |
|
| 34 |
|
| 35 |
I did have a go at hooking portage before, but rather overengineered |
| 36 |
it ;) but here's what I'm thinking now, as an evolution of (2), is to |
| 37 |
add a QA check to portage, either directly in portage itself or perhaps |
| 38 |
as a bashrc hook. The check would: |
| 39 |
|
| 40 |
a) monitor PaX marking on files as they go to be installed. The swiss |
| 41 |
army knife that is scanelf helps enormously here, and should make |
| 42 |
verification quick |
| 43 |
b) by default use a policy file (i.e. list of non-standard executables |
| 44 |
and PaX markings) distributed with the profiles. This allows for |
| 45 |
variations according to arch, which may be useful, and makes it easy |
| 46 |
to maintain and distribute. |
| 47 |
c) forcibly set the PaX relaxations, conditionally on a make.conf var. |
| 48 |
d) Deal with the chpax strip problem in prepstrip. |
| 49 |
|
| 50 |
I'm not sure there's an ideal hooking point; I would want to be after |
| 51 |
stripping but before the vdb data is collated. If it has to be before |
| 52 |
stripping, portage would need to be tweaked to avoid wiping chpax flags |
| 53 |
in prepstrip (a save/restore should be easy enough). |
| 54 |
|
| 55 |
Enough for now... |
| 56 |
-- |
| 57 |
Kevin F. Quinn |
| 58 |
|
| 59 |
|
| 60 |
-- |
| 61 |
Kevin F. Quinn |
Archives