Proactive Security

[Lorenzo Hernandez Garcia-Hierro]

Hi John,

El mié, 27-10-2004 a las 20:10, John Richard Moser escribió: 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> I would like to discuss proactive security enhancements to Ubuntu Linux
> and, eventually, to Debian GNU/Linux.  I and others have recently been
> interested in merging such security ehancements into Debian; and any
> work done could be shared between both Ubuntu and Debian, as they are so
> close.

That's the point and what i was thinking about, and that's the reason
because *we* started Hardened Debian.

> There is already a Wiki article[1] on Ubuntu's wiki about the topic.  It
> would be prudent to examine this and begin discussion of the topic at
> earliest convenience.
> 
> [1] http://wiki.ubuntu.com/ProactiveSecurity
> 
> The direction taken should involve an experimental branch of the
> Debian/Ubuntu development packages.  Particularly, modifications to
> build PIE/SSP packages and to allow a specific list of packages which
> cannot cope with PIE/SSP to be considered (and thus, to affect the build
> process by disabling PIE and/or SSP in such cases) should be created and
> tested.

Maybe that can be reliable using the wanna-build stuff, but i haven't
tested it by the moment.
Anyway, PIE overload on standard binaries wouldn't harm the final
execution time and resources consumption, AFAIK, you have more results
about that.

> The development of Ubuntu can be tested in lab (i.e. on the maintainers'
> machines) and in beta when appropriate.  Packages breaking with the
> added security can have the security disabled for them, and the settings
> noted.  When the majority of packages inable to cope are hunted out,
> Ubuntu can ship with the protections.

Yeah, we must mind that more security doesn't need to mean less
usability, and in most cases the interaction with the user is not needed
and changes are made transparently.

> If the protections are not ready when Ubuntu's release cycle comes
> about, then the protections need not be implemented; all packages can be
> simply rebuilt as normal for the release in a predictable measure of
> time, and should already exist as such for better testing in prediction
> of such a case anyway.  It is, however, a decision for the developers if
> they would prefer to hold Ubuntu back.  No assertion to that end is made
> here; a new release without security is no more a problem than simply
> leaving users with the older release, and indeed may be a good thing
> anyway, as older software may have more bugs and potential security
> vulnerabilities.

I agree with that.

> It is not a severe problem if an obscure software package is found after
> shipping to break under the new security scheme, although all core
> packages must operate properly.  Upon the discovery of this, the Ubuntu
> maintainers may simply rebuild or remark the package (depending on what
> breaks it) and ship a new version of that to the mirrors for affected
> releases.  Alternately, and possibly more cleanly, they may attempt to
> debug the package and determine why it breaks, and fix the error;
> however, this would require work which is really the responsibility of
> upstream.

That makes sense if we want to make the releasing process more
reliable,i think it's the best way too.

> I look forward to discussing the potential for implementing such things.
> ~ The Hardened Debian[2] project may have some utilities to offer up to
> this end, and may be willing to work with Ubuntu's developers to meet
> these goals.
> 
> [2] http://www.debian-hardened.org/

From my part, I'm able and interested for contributing and working
together with Ubuntu developers, as i agree completely with the project
philosophy, but when i was talking n #ubuntu-devel with you, some of the
developers had bad experiences with some of the features we are working
on, mainly they were talking about Exec Shield, which is not used/worked
out by us, instead of PaX (which is the ne that we are using) that has
much more stability and effort in it, and those are the things that need
to be "fixed", and I would be happy providing working stuff about all of
these things, to demonstrate that many things aren't as bad they could
think.

At the D-SbD project package there are many documents talking about
this, and i recommend to read them first, as a start point of getting in
the rid of the capabilities and features that we are developing.

Cheers,
-- 
Lorenzo Hernandez Garcia-Hierro <lorenzo at gnu.org>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Esta parte del mensaje =?ISO-8859-1?Q?est=E1?= firmada
	digitalmente
Url : http://lists.ubuntu.com/archives/ubuntu-devel/attachments/20041109/ed857366/attachment.pgp