Security in Debian: a discussion

Good things

Work of the Security Team, average for a vuln to be fixed 30,5 days,
	mean is 7 days.
We are behind other Security Teams (RedHat on average 17,9 days, Mandrake
on average 26,13 days) but:
	we provide more architectures*releases (they, more release, us
	more archs)
	the Security Team/DD are not getting paid for this
(difficult comparison with others, like Conectiva, but probably better)

Security-related tools/patches: quite a number of them, users/developers 
	can use Debian boxes to provide security systems and assess security.
	"White-hack" toolkit.

Minimal installation, no network services

Default secure setups of daemons and services.

Make an effort to be "there" in security standards: CVE-references, OVAL
work.

Insert ECOL strip

Bad things:
(Let's whine)

Takes more time as time passes by
1999 - average 1,3 days mean 3,5 (16)
2000 - average 17,3 days mean 2 (45)
2001 - average 15,8 days mean 6 (52)
2002 - average 42,6 days mean 9 (115)
2003 - average 80,4 days mean 63 (14)

A constant increase of DSAs:
	DSAs in 1997: 17
	DSAs in 1998: 43
	DSAs in 1999: 38
	DSAs in 2000: 66
	DSAs in 2001: 85
	DSAs in 2002: 124
	DSAs in 2003: 111 (july 11th)

Slink (unknown, no priority in Sources)
Potato DSAs: 6 required, 10 important, 17 standard, 24 extra, 140 optional
Woody DSAs: 1 to important, 3 to required, 11 standard, 41 extra, 139 optional

	Compare vs. CERT and Bugtraq reports of vuln increase
We have more software -> we have more DSAs. Obvious but true.

Transparency is not good
	Users are "left in the dark" security team is not using DSAs to
	announce "work in progress". Sample: kernel ptrace hole.
	security.debian.org does not publish "WIP" only DSAs sent.

In the technical side we do lack some things that do not make Debian
a "good" choice in some environments:
	- no fully "secure" downloads: no encrypted connections (an attacker
	  could "see" a system is vulnerable), not vulnerable to spoofing
	  (mitm attacks to Debian systems), no checks for downloaded
	  packages (mitm). Fix it: SSL, Signed support in packages
	  (for the security area), _automatic_ support of signed
	  releases [RedHat is doing this]
	- also security.debian.org is a SPOF
	- no formal security audits done (some efforts, but full support)
	- full compartimentalization of services (ala chroots but maybe w/o
	  them) [OpenBSD is doing this]

Security tools in stable turn old, render them useless: chkrootkit will
not detect newer problems, nessus won't, Snort won't, Tiger won't.
Backport security (defensive?) tools?

It is difficult to do some security enhancements (sample: kernel patches
might not apply properly, no secured kernels)

DD access, why do we keep old developers around? They might lose keys/passwords accesing remote servers -> compromise of a Debian server...
	
Possible improvements:

- Security audit task force, integrated with other's (OpenBSD)

- Add a "risk" level in the DSAs based on exposure, package popularity...

- Compartimentalization of all services, full user separation: _no_
  system running as root

- Raise user awareness: publish information on pending stuff on DSAs
  (SuSE does this) and publish at the website. Develop a tracking
  database which can expose a public interface.

- Automatic system checks upon receiving an announcement (a simple way
  to check if you are not uptodate if you do not have HTTP/FTP access
  or it is slow), checking manually package information is not easy
  when DSAs # increase
  	- provide a service for users to receive DSAs based on profiles
	  (careful, careful): Cassandra, RHN
	- provide a comprehensive way to check upon receival: OVAL?

- Hardened distro. Trusted Debian looked nice but is not a community
  effort (Adamantix) #81118
  	- depend on non-trusted software
	- replace software with trimmed down counterparts (can this be
	  done with dpkg? IF the user has X 
	- Provide pre-configuration for Firewalls+IDS system
	- task-secure-server?
  [Mandrake is doing this through security levels, RedHat latest release
   help firewall customization on installation]
	- recompilation with libsafe?
   	- latest OpenBSD looks cool, port?
	- at least provide a 'security enhanced' kernel on installation.

- Maybe setup a project to do a Knoppix-based CD
  for audits (personal pet project)

- 'Secure update' button for GNOME/KDE - KISS

- 'Security in testing' - No security. Is it worth doing security uploads?

Goals:
- prevent security issues in our users
- help keep up-to-date Debian systems (eased by our wonderful package
  management tools but can be improved)
- make Debian stand as a secure distribution, despite it's done in our spare
  time :-)
- CC Certification? (money, and mostly for advertisement)

Bottom line: please help up in security initiatives!