Some Ideas for Debian Security Improvements

Debian security is pretty good, but there’s always scope for improvement. Here are some ideas that I think could be used to improve things.

  1. A security “wizard”, basically a set of scripts with support for plugins that will investigate your system and look for things that can be improved. It could give suggestions on LSMs that could be used, sysctl settings, lists of daemons running as root that possibly don’t need root privs, etc. Plugins could be for different daemons, so there could be a plugin for Apache that looks for potential issues with Apache configuration. It wouldn’t be possible to cover everything, but it would be possible to cover many common cases.
    It appears that we used to have a “harden” package to do some of these things which disappeared. It appears that the only remnant of that is the hardening-runtime package.
  2. Kali Linux [1] is a distribution designed for penetration testing, I recently tried out many of it’s features and I was very impressed. While I don’t think that the aim should be to copy all Kali features into Debian there are probably some that are worthy of inclusion. Most Kali features run well in a VM, but the Wifi penetration testing tools need access to the hardware, so they could be a good candidate for inclusion in Debian (license permitting).
  3. We have a Securing Debian Manual [2] that is really good. It’s a little out of date and needs some contributions, it also needs to be better known.
  4. The Security Management page of the Debian wiki [3] has links to a number of pages about improving system security. It needs some updates, it doesn’t have a link to a page about SE Linux so there’s some work for me to do there.
  5. Can training help people? I would be happy to run some Debian SE Linux training sessions over Matrix or Jitsi. We can probably find people to offer training on other aspects of Linux security that are implemented in Debian if there is an audience. I don’t think that I and other DDs (Debian Developers) can train everyone, but we could train people who then go on to run other training sessions and make the session notes etc available under the GPL.
    There would also be some benefits to training other DDs as probably no-one has a good overview of all the security features that are supported.

Any other ideas? Feel free to comment here or start a thread on a public mailing list. If you start a mailing list discussion please email me or comment here with the URL if it’s a list that I’m not on so I can track it via the archives. This post was inspired by a discussion on a private list of a related topic. I think it’s better to have a public discussion instead.

3 comments to Some Ideas for Debian Security Improvements

  • Andrew Cater

    * Kali pen testing tools in every Debian – maybe not a good idea. It’s hard enough for most people to do an install with working wifi.
    * If you want a “harden” profile, then the answer would perhaps be to produce a profile that matches CIS guidelines and another that would implement whatever’s needed for PCI and credit card transactions.

  • Someone

    Yeah, have up to date browsers with security fixes in stable.

  • Andrew: There are many packages in Debian that can’t be installed easily or by novices. Some are so difficult that I’ve given up on them. As long as they aren’t in a major dependency chain it doesn’t matter, if someone chooses to do something difficult then they should expect that installing and using the packages in question won’t be really easy.

    Sure we could have profiles for PCI etc, that would be very useful for some people. But I’m more interested in my use cases of small business servers and home servers that should be reasonably secure without too much effort.

    Someone: There are technical difficulties in that. Google packages Chrome for Debian and keeps it up to date regularly.

Leave a Reply

You can use these HTML tags

<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>