Re: Improving security for pkgsrc

[Pierre Pronchery <khorben%defora.org@localhost>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

			Hi,

On 07/29/15 01:27, Greg Troxel wrote:
>>>> 2b. support gets added for more platforms 3. enabling by 
>>>> default on NetBSD/gcc (possibly also clang), possibly 
>>>> partially (like for base)
>>> 
>>> To get to this, we probably need a SSP_SAFE=no define for 
>>> individual packages.  And confidence that we aren't causing 
>>> undetected/unknown breakage.
>> 
>> But then if it does break, and a bug is confirmed, is it not 
>> better to break rather than expose a weird machine to potential 
>> attackers?
> 
> It's not reasonable to decide that for other people, because none 
> of us know the shape of their utility functions.  Some people
> would rather turn off SSP and have their software still work, and
> some people would rather stop using the software because it's
> dangerous. The pkgsrc way is to let users make that call.  This is
> not so different from setting ALLOW_VULNERABLE_PACKAGES.  I suspect
> a non-trivial number of people do that.

Exactly: the default behavior for ALLOW_VULNERABLE_PACKAGES prevents
vulnerable packages from being installed, except if the user did
explicitly set it. How is SSP different?

I do not see any reason to not fail-safe here.

>>>> 4. fail if enabled but not supported for the current 
>>>> platform
>>> 
>>> That really doesn't seem useful.  Let's defer this until after 
>>> it's the default for NetBSD/gcc.
>> 
>> To me it is the complete opposite. A user should not be let into 
>> a dangerous direction without a big, fat warning and a barrier
>> to jump before falling off the bridge. We are operating a bridge 
>> here. 
>> http://allday.com/post/4658-11-of-the-dumbest-and-most-unusual-ways-p
eop
>>
>> 
le-have-died/pages/2/
> 
> By that logic we should disable pkgsrc completely until all known 
> mitigations are implemented.  In all seriousness, it's ok to make 
> things better, but I don't think it's ok to start breaking things 
> that used to work.

Compiler bugs aside, we would not be breaking things that used to
work, but breaking things that /seemed/ to work.

Anyway, as mentioned before, I totally agree to proceeding in steps and
we should. So let's first detect and solve obvious breakage if any,
and I really hope we will be in a situation where we can change the
default without known breakage earlier than not.

What about enabling it when PKG_DEVELOPER is enabled?
(possibly in another step)

> But, I'm not averse to adding SSP_SAFE=no to programs that are 
> known to have issues, and heading to enabling PKGSRC_USE_SSP by 
> default when we believe that the number of packages  which should 
> have SSP_SAFE=no set but don't is low.

On my local system devel/cmake refuses to build, which may however not
be related (I have a number of other changes). If confirmed, this
might be a first candidate for SSP_SAFE=no.

Cheers,
- -- 
khorben
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIcBAEBAgAGBQJVuBSdAAoJEDA4y9uYhpcDAo8QAK4ImE99efUrtI+NzUVbQvn0
1pjfXinI08uIQyR2V8aUpPMbSS1IK4s+7UrZTIHNQoHPaOxV0iYviLTDjU+IRLSg
zEfM6HhW3WFg/jy0g8AyXfJpKxuoz1GUrvSXKM+0s1PjLVyf6SiSyA0aI/ZkfMqQ
hmkaz1k+8FfUq1/9ah7cFzD7arPye5FaUKnQ7CTUTHqGDjy8MebveJBEJlcbOBYJ
ZjjPfthBizaj0M3M6d4dRQvKk4RebCoNt5ZlDaPUIKXfznC8ELM0j1cuimzd1Oi+
xGumDVfnzglN6JKgepKp2MEIfUCf1S8mBjL8LiX07X/aZosPpqkpv6tw0lNcqSTx
UV4m9sMnx2afmKxlVAvUGUnQTkg8Q7ltTwaLyybQBj28Mbv9TRpFvXM4GniuQUV6
P+7WNPUf4jTM+3yaefCOkz6pKUWjLBIRAjDYsQT9BngqYZoeCQohCok8Lk32szXT
1Q/dfOcK3kkE4vlvJYhjOiJ5n+ZlK23eCUadMAfKk8l/gL8FKwxZOhJ5n+OtSBnF
9uK7RDvIoA6WCzkTJYFA1LtU7mxFa6KE3spY8jM+jAMnHyW5fDgfJ30eyN9zYBpz
l0063ItYhFlxt04Z/ckVdYTHht8ttfty/tC7Sj1oy4sHv7qyGTAscasj2h26geDx
91auwibYEVKidibLTbVb
=5EFO
-----END PGP SIGNATURE-----