[arch-dev-public] providing grsecurity in [community]

Daniel Micay danielmicay at gmail.com
Thu Apr 17 02:44:37 EDT 2014

On 16/04/14 06:00 AM, Thomas Bächler wrote:
> Am 16.04.2014 11:52, schrieb Allan McRae:
>> On 16/04/14 17:25, Daniel Micay wrote:
>>> On 16/04/14 03:15 AM, Daniel Micay wrote:
>>>> Pacman hooks would
>>>> be a nicer solution than editing all the install scripts, but we don't
>>>> have those :).
>>> It also wouldn't be nearly as bad if packages could store extended
>>> attributes, since the ugly install scripts could be avoided and paxctl
>>> would only be a make dependency. Packages like iputils already run into
>>> this issue due to using capabilities as a replacement for setuid.
>> Just submitted a patch to pacman that will allow setting capabilites in
>> the package() function.
> Since we want PAX support to remain optional, we'd still need hooks so
> that after each upgrade, a script can adjust the flags appropriately.

It would have no impact on people not using it, since it would just be a
very short string set in the `user.pax.flags` xattr key. For example,
`setfattr -n user.pax.flags -v "mr" "$pkgdir/usr/bin/foo"` to disable
MPROTECT and RANDMMAP features (on chromium, firefox, etc.).

Of course, I'm imagining a future utopia where a critical mass of
developers / trusted users are interested in maintaining this kind of
thing. For the near future, users would just keep using the scary
linux-pax-flags package if they wanted to enable PaX via sysctl.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: OpenPGP digital signature
URL: <http://mailman.archlinux.org/pipermail/arch-dev-public/attachments/20140417/ac5f5063/attachment.asc>

More information about the arch-dev-public mailing list