Mailing List Archive

Hi Anthony,

Is user.* xattrs on tmpfs considered safe now? (Referring to
meeting-2012-11-14_20_00UTC.log.)

As a side note, why does XATTR_PAX use user.* and not security.* namespace?

--
Maxim Kammerer
Liberté Linux: http://dee.su/liberte

On 12/22/2012 05:58 PM, Maxim Kammerer wrote:
> Hi Anthony,
>
> Is user.* xattrs on tmpfs considered safe now? (Referring to
> meeting-2012-11-14_20_00UTC.log.)
>
> As a side note, why does XATTR_PAX use user.* and not security.* namespace?
>

An updated patch by pipacs limits tmpfs to just user.pax.* namespace,
and even then there is a size limit. The size check is critical and
what was originally missing.

XATTR_PAX uses user.* so that a non-privileged user can set flags on
their own ELF objects as they can with PT_PAX. Primarily the concern is
on processes running as root. There PaX hedges against escalation.
There is no danger of escalation when it comes to processes that below
to a low privileged user.

--
Anthony G. Basile, Ph. D.
Chair of Information Technology
D'Youville College
Buffalo, NY 14201
(716) 829-8197

Hi!

On Sat, Dec 22, 2012 at 12:13:26PM -0500, Anthony G. Basile wrote:
> The best way to get to know what its all about is to help me with the
> documentation. I'll upload it after discussion. Its at
>
> http://dev.gentoo.org/~blueness/zzz/pax-quickstart.xml
>
> It describes pretty much anything. Give it a read and let me know what
> you think should be added.

Actually I think a lot should be removed instead. Right now it's
overcomplicated and overloaded with useless internals/details.
The name "QuickStart" suppose it to be read by end-users, especially ones
which wanna do their work fast without deep digging.

There are too many ways to do same things, and too many tools doing same
things. I think it makes more sense to concentrate on user's use cases,
instead of implementation details.

Such use cases as:
- how to quickly convert my system to XATTR_PAX
- how to quickly convert it back PT_PAX
- which ordinary operations may damage/drop PaX settings on elf
(should mention things like minimal tar version which preserve xattrs,
issues with copying/moving/scping/etc., …)
- is ebuilds which currently do paxmarking will automatically use
XATTR_PAX when it's enabled?
- what happens with custom xattrs on file after re-emerging package
containing that file?
- how to find and paxmark all binaries which use libraries like libGL.so.1
And the less tools you'll use to do these tasks - the better.


P.S. One more possible typo which I forget to include in personal email to
you: at "Code Listing 5.4: paxctl -h" flag "-d" mentioned in "Usage" but
not documented in "Options".

--
WBR, Alex.

On Dec 27, 2012 6:08 AM, "Alex Efros" <powerman@powerman.name> wrote:
> Actually I think a lot should be removed instead. Right now it's
> overcomplicated and overloaded with useless internals/details.
> The name "QuickStart" suppose it to be read by end-users, especially ones
> which wanna do their work fast without deep digging.

I disagree but understand your viewpoint. Perhaps a first chapter on
"quickly deploying pax markings" and then more elaborate information? I
would hate to see the information go away...

On 12/27/2012 12:26 AM, Sven Vermeulen wrote:
> On Dec 27, 2012 6:08 AM, "Alex Efros" <powerman@powerman.name> wrote:
>> Actually I think a lot should be removed instead. Right now it's
>> overcomplicated and overloaded with useless internals/details.
>> The name "QuickStart" suppose it to be read by end-users, especially ones
>> which wanna do their work fast without deep digging.
>
> I disagree but understand your viewpoint. Perhaps a first chapter on
> "quickly deploying pax markings" and then more elaborate information? I
> would hate to see the information go away...
>
I don't think it should go away, just have a quickstart and a deepdive.

--
-- Matthew Thode (prometheanfire)

On 12/27/2012 01:47 AM, Matthew Thode wrote:
> On 12/27/2012 12:26 AM, Sven Vermeulen wrote:
>> On Dec 27, 2012 6:08 AM, "Alex Efros"<powerman@powerman.name> wrote:
>>> Actually I think a lot should be removed instead. Right now it's
>>> overcomplicated and overloaded with useless internals/details.
>>> The name "QuickStart" suppose it to be read by end-users, especially ones
>>> which wanna do their work fast without deep digging.
>>
>> I disagree but understand your viewpoint. Perhaps a first chapter on
>> "quickly deploying pax markings" and then more elaborate information? I
>> would hate to see the information go away...
>>
> I don't think it should go away, just have a quickstart and a deepdive.
>

http://www.youtube.com/watch?v=IoY0Qa0zU0A

--
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail : blueness@gentoo.org
GnuPG FP : 8040 5A4D 8709 21B1 1A88 33CE 979C AF40 D045 5535
GnuPG ID : D0455535

On 22 Dec 2012 at 12:13, Anthony G. Basile wrote:

> http://dev.gentoo.org/~blueness/zzz/pax-quickstart.xml
>
> It describes pretty much anything. Give it a read and let me know what
> you think should be added.

some notes:

> Note that if you enable both PT_PAX and XATTR_PAX, then the kernel expects
> both fields to be identical, otherwise neither field is respected.

this is almost true ;). what the kernel expects is that if *both* methods
are enabled in the kernel config *and* set on the userland binaries then
they have to be identical. notably this leaves the possibility to *not*
specify the user.pax.flags xattrs at all on the binaries yet still enable
XATTR_PAX support in the kernel safely: such binaries will simply run with
the highest protection by default, much like in the old days of EI_PAX.

this also means that there's no chicken and egg problem despite what this
says:

> [...]but now we have a chicken and the egg problem: we don't have XATTR_PAX
> markings on our ELF objects, but we're asking the kernel to respect them.

you can safely disable PT_PAX support in the kernel and enable only XATTR_PAX
and the resulting system will run all your binaries with the most secure settings
(i.e., with non-exec pages, mprotect and aslr enabled). you'll only have to
set xattrs on the binaries where some of these have to be relaxed (mprotect
on java, etc), i.e., all this migration should *not* blindly set user.pax.flags
on all userland binaries but only on those that need something disabled (or
in case of emutramp, enabled). i believe this makes the whole migration much
easier.

On 01/04/2013 08:24 PM, PaX Team wrote:
> On 22 Dec 2012 at 12:13, Anthony G. Basile wrote:
>
>> http://dev.gentoo.org/~blueness/zzz/pax-quickstart.xml
>>
>> It describes pretty much anything. Give it a read and let me know what
>> you think should be added.
>
> some notes:
>
>> Note that if you enable both PT_PAX and XATTR_PAX, then the kernel expects
>> both fields to be identical, otherwise neither field is respected.
>
> this is almost true ;). what the kernel expects is that if *both* methods
> are enabled in the kernel config *and* set on the userland binaries then
> they have to be identical. notably this leaves the possibility to *not*
> specify the user.pax.flags xattrs at all on the binaries yet still enable
> XATTR_PAX support in the kernel safely: such binaries will simply run with
> the highest protection by default, much like in the old days of EI_PAX.
>
> this also means that there's no chicken and egg problem despite what this
> says:

Nice! I did not know that.

>
>> [...]but now we have a chicken and the egg problem: we don't have XATTR_PAX
>> markings on our ELF objects, but we're asking the kernel to respect them.
>
> you can safely disable PT_PAX support in the kernel and enable only XATTR_PAX
> and the resulting system will run all your binaries with the most secure settings
> (i.e., with non-exec pages, mprotect and aslr enabled). you'll only have to
> set xattrs on the binaries where some of these have to be relaxed (mprotect
> on java, etc), i.e., all this migration should *not* blindly set user.pax.flags
> on all userland binaries but only on those that need something disabled (or
> in case of emutramp, enabled). i believe this makes the whole migration much
> easier.
>


--
Anthony G. Basile, Ph. D.
Chair of Information Technology
D'Youville College
Buffalo, NY 14201
(716) 829-8197