Proactive Security
John Richard Moser
nigelenki at comcast.net
Wed Oct 27 13:10:00 CDT 2004
-----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.
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.
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.
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.
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.
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/
- --
All content of all messages exchanged herein are left in the
Public Domain, unless otherwise explicitly stated.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFBf+R0hDd4aOud5P8RAhuzAKCHnIaVQOwaaaPkZHOJ20zkmePJqACdG/P1
LSk+QCRY32MITdrRMXD/xIo=
=U1/l
-----END PGP SIGNATURE-----
More information about the ubuntu-devel
mailing list