portage does not uninstall files that have been modified by paxctl or chpax

Hi!

As kevquinngentoo.org 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 think quick dirty fix can be as simple as:

---/etc/portage/bashrc:---
if [ "$" == "postinst"
]; then
    /etc/set_pax
fi
---cut---

but I'm not sure about sandbox paths at this stage - which
path should be
used in /etc/set_pax script:
    chpax -flags /usr/bin/SOMETHING
or
    chpax -flags
$/usr/bin/SOMETHING

-- 
			WBR, Alex.
-- 
gentoo-hardenedgentoo.org mailing list

On Tue, 6 Jun 2006 17:05:14 +0300
Alex Efros <powermanpowerman.asdfGroup.com> wrote:

> As kevquinngentoo.org 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