Mailing List Archive

On 12/18/2014 07:09 PM, Anthony G. Basile wrote:
> Hi fellow hardened devs:
>
> I'm sorry for missing the meeting but things came up and the day got
> hectic. It is an important meeting because we were to discuss:
>
> 1) what we want with toolchain.eclass - There is a move to get rid of
> the eclas because it is "messy". This is probably a bad thing in
> general and especially for hardened so we should discuss the pros and
> cons and what we want.
>
> 2) what to do about tar and POSIX capabilities in the context of
> building stage3's. Utilities like ping that used to be setuid to root
> are now just using posix caps. But preserving xattrs with tar is
> tricky. Since we dealt with this for the user.pax.* xattr namespace
> jmbsvicetto asked us to look at security.capability. However, the issue
> may now be mute because I just got a message from him that
>
> tar --xattrs --xattrs-include=security.capability
> --xattrs-include=user.* --acls -xjpvf
>
> works to get us all the xattr goodies we need for hardened and gentoo in
> general.
>
>
> We should try to discuss 1 soon-ish before Cthulu awakens and madness
> reigns in gentoo.
>
regarding 1: a refactoring is in order probably, but what are the
specific complaints?

regarding 2: The thing we need to ask is if we want to ask users to run
that to extract stage3 tarballs, instead of -xf and the like.

--
-- Matthew Thode (prometheanfire)

On Dec 19, 2014 2:38 AM, "Matthew Thode" <prometheanfire@gentoo.org> wrote:
>
> On 12/18/2014 07:09 PM, Anthony G. Basile wrote:
> > 2) what to do about tar and POSIX capabilities in the context of
> > building stage3's. Utilities like ping that used to be setuid to root
> > are now just using posix caps. But preserving xattrs with tar is
> > tricky. Since we dealt with this for the user.pax.* xattr namespace
> > jmbsvicetto asked us to look at security.capability. However, the issue
> > may now be mute because I just got a message from him that
> >
> > tar --xattrs --xattrs-include=security.capability
> > --xattrs-include=user.* --acls -xjpvf
> >
> > works to get us all the xattr goodies we need for hardened and gentoo in
> > general.
> regarding 2: The thing we need to ask is if we want to ask users to run
> that to extract stage3 tarballs, instead

What xattrs are there in the tarball that we don't want our users to
install?

Wkr,
Sven Vermeulen

On 12/19/2014 12:02 AM, Sven Vermeulen wrote:
>
> On Dec 19, 2014 2:38 AM, "Matthew Thode" <prometheanfire@gentoo.org
> <mailto:prometheanfire@gentoo.org>> wrote:
>>
>> On 12/18/2014 07:09 PM, Anthony G. Basile wrote:
>> > 2) what to do about tar and POSIX capabilities in the context of
>> > building stage3's. Utilities like ping that used to be setuid to root
>> > are now just using posix caps. But preserving xattrs with tar is
>> > tricky. Since we dealt with this for the user.pax.* xattr namespace
>> > jmbsvicetto asked us to look at security.capability. However, the issue
>> > may now be mute because I just got a message from him that
>> >
>> > tar --xattrs --xattrs-include=security.capability
>> > --xattrs-include=user.* --acls -xjpvf
>> >
>> > works to get us all the xattr goodies we need for hardened and gentoo in
>> > general.
>> regarding 2: The thing we need to ask is if we want to ask users to run
>> that to extract stage3 tarballs, instead
>
> What xattrs are there in the tarball that we don't want our users to
> install?
>
> Wkr,
> Sven Vermeulen
>
not a question about trust, but one of added complexity :D

--
-- Matthew Thode (prometheanfire)

On 12/18/14 20:36, Matthew Thode wrote:
> On 12/18/2014 07:09 PM, Anthony G. Basile wrote:
>> Hi fellow hardened devs:
>>
>> I'm sorry for missing the meeting but things came up and the day got
>> hectic. It is an important meeting because we were to discuss:
>>
>> 1) what we want with toolchain.eclass - There is a move to get rid of
>> the eclas because it is "messy". This is probably a bad thing in
>> general and especially for hardened so we should discuss the pros and
>> cons and what we want.
>>
>> 2) what to do about tar and POSIX capabilities in the context of
>> building stage3's. Utilities like ping that used to be setuid to root
>> are now just using posix caps. But preserving xattrs with tar is
>> tricky. Since we dealt with this for the user.pax.* xattr namespace
>> jmbsvicetto asked us to look at security.capability. However, the issue
>> may now be mute because I just got a message from him that
>>
>> tar --xattrs --xattrs-include=security.capability
>> --xattrs-include=user.* --acls -xjpvf
>>
>> works to get us all the xattr goodies we need for hardened and gentoo in
>> general.
>>
>>
>> We should try to discuss 1 soon-ish before Cthulu awakens and madness
>> reigns in gentoo.
>>
> regarding 1: a refactoring is in order probably, but what are the
> specific complaints?

mgorny doesn't like it and says its intrusive. I was not able to get
more out of him. See

https://www.marc.info/?l=gentoo-dev&m=141804148612262&w=2

>
> regarding 2: The thing we need to ask is if we want to ask users to run
> that to extract stage3 tarballs, instead of -xf and the like.
>

Also responding to Swift. Since we build the stage3's we decide what
xattrs get in there from what is set by the ebuilds --- "we" = any
gentoo dev via the ebuild he/she writes. The question then is up to us
what we want. Right now we are including only security.capability and
user.pax.flags. releng has adopted a blacklist policy where all xattrs
are excluded unless we specifically include them. So acls and selinux
are not included.

Note: this is just what gets into the stage3 tarball. Once unpacked,
the user is free to set whatever xattrs he/she wants.

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

On Thu, Dec 18, 2014 at 08:09:01PM -0500, Anthony G. Basile wrote:
> Hi fellow hardened devs:
>
> I'm sorry for missing the meeting but things came up and the day got
> hectic. It is an important meeting because we were to discuss:
>
> 1) what we want with toolchain.eclass - There is a move to get rid of
> the eclas because it is "messy". This is probably a bad thing in
> general and especially for hardened so we should discuss the pros and
> cons and what we want.

I quite dislike the eclass, it breaks stable systems whenever there is
any change to it. A recent one that broke things for me was when the
sanitize useflag was added to stable ebuilds which broke all my crossdev
toolchains. (it was defaulted to enabled and im not sure there was much
testing and sanitizing makes no sense on AVR or other bare metal
microcontrollers.)

Another thing is the differences between gcc versions. with most
packages its pretty simple to see changes with diff -u but that doesn't
work obviously. I find using diff a lot easier than stuff like this:

if tc_version_is_at_least 4.6 ; then
LICENSE="GPL-3+ LGPL-3+ || ( GPL-3+ libgcc libstdc++ gcc-runtime-library-exception-3.1 ) FDL-1.3+"
elif tc_version_is_at_least 4.4 ; then
LICENSE="GPL-3+ LGPL-3+ || ( GPL-3+ libgcc libstdc++ gcc-runtime-library-exception-3.1 ) FDL-1.2+"
elif tc_version_is_at_least 4.3 ; then
LICENSE="GPL-3+ LGPL-3+ || ( GPL-3+ libgcc libstdc++ ) FDL-1.2+"
elif tc_version_is_at_least 4.2 ; then
LICENSE="GPL-3+ LGPL-2.1+ || ( GPL-3+ libgcc libstdc++ ) FDL-1.2+"
elif tc_version_is_at_least 3.3 ; then
LICENSE="GPL-2+ LGPL-2.1+ FDL-1.2+"
else
LICENSE="GPL-2+ LGPL-2.1+ FDL-1.1+"
fi

I understand why people like the eclass and I think some of the reasons
are good but I think there is far too much stuff in the eclass and a lot
of it should be moved into the ebuilds. Especially if there is a feature
in a new version of gcc, why take the risk that older stable versions
will break when things are added to the eclass?

Perhaps a cleaner approach would be to split things into eblits like
glibc or perl does? Then there can be one per 4.x version of gcc instead
of having a single eclass that has to support all the way from gcc-2.95
up to gcc-4.9 and all the associated craziness.

-- Jason