On Tue, 6 Jun 2006 17:05:14 +0300 Alex Efros <[EMAIL PROTECTED]> wrote:
> As [EMAIL PROTECTED] says, discussion about this bug probably > should be moved into hardened maillist: > > Clear-Text: http://bugs.gentoo.org/show_bug.cgi?id=134620 > Secure: https://bugs.gentoo.org/show_bug.cgi?id=134620 I was thinking more along the lines of discussing the management of PaX marking in general, with the intention of determining a policy we can apply consistently. Basic options as I see it come down to 1) Have ebuilds set the PaX relaxations that are particular to that app Pros: makes it easy for apps to work on non-MAC PaX systems Cons: user may be unaware of what has been relaxed (creates a "default relax" for affected apps) 2) Have ebuilds do no such thing, and manage the markings externally. This is a kind of poor-man's MAC, in as much as it consists of a central file listing everything that might be relaxed. With init.d/chpax this is, "enforced" by a start-up script. Pros: policy is clear, for the sysadmin Cons: we need to maintain the policy file if done outside of portage, messes up unmerges The problem highlighted on the bug is that approach (2) as currently implemented by the init.d/chpax script messes the mtime/md5sum of files thus causing portage to avoid removing them when packages are unmerged. Further complications come from the variation in PaX DAC markings; vis. chpax vs paxctl, noting also that chpax markings are lost on strip. I did have a go at hooking portage before, but rather overengineered it ;) but here's what I'm thinking now, as an evolution of (2), is to add a QA check to portage, either directly in portage itself or perhaps as a bashrc hook. The check would: a) monitor PaX marking on files as they go to be installed. The swiss army knife that is scanelf helps enormously here, and should make verification quick b) by default use a policy file (i.e. list of non-standard executables and PaX markings) distributed with the profiles. This allows for variations according to arch, which may be useful, and makes it easy to maintain and distribute. c) forcibly set the PaX relaxations, conditionally on a make.conf var. d) Deal with the chpax strip problem in prepstrip. I'm not sure there's an ideal hooking point; I would want to be after stripping but before the vdb data is collated. If it has to be before stripping, portage would need to be tweaked to avoid wiping chpax flags in prepstrip (a save/restore should be easy enough). Enough for now... -- Kevin F. Quinn -- Kevin F. Quinn
signature.asc
Description: PGP signature
