Promoting Linux Requires Advertising. That's What Counts. ^TM

Linux Security Wish List

Lots of security-related tools appear to be broken, half-functional, unfinished and otherwise in disarry, in Linux. Below is a list of notes of what's broken, what needs doing.

/etc/passwd ulimit=: The man (5) passwd man page indicates that one can set the ulimit in the passwd file. This is deprecated; a note should be added indicating that the right way to do this is to edit /etc/security/limits.conf and configure /etc/pam.d to use this file. Note that /etc/login.defs continues to mention ulimit ... status here needs to be clarified.
/etc/login.defs: Contains XXX remarks from Juliane Haugh regarding the nologin, the status needs to be clarified.
/etc/security/limits.conf: This file needs to contain a comments indicating which subsystem uses it. (Its PAM that uses it). Under Debian unstable, with the current PAM config, the default config has this file ignored (this should be fixed). In other words, su - root followed by "su - someuser" doesn't seem to set any limits. One must edit files in /etc/pam.d to fix this. Need a man page for this file.
setpcaps: This package is insanely out of date and needs a thorough re-write and expansion. Its missing manpages, the output of getpcap is totally cryptic. setpcap is unusable for taking away caps. This may be due to a kernel design flaw: there should probably be one SYS_PCAP that allows caps to be reduced, another for them to be increased.
bind9/named: The default Debian install for bind9/named needs to be in a chrooted environment. I'm guessing the debian maintainer hasn't done this because its not the default upstream, and also, LFHS file hierarch standard doesn't deal with chrooted environments.
Apache: Needs to be a lot easier to chroot. Too complex right now.
User Logins/ssh/pam/passwd ??: Most users on a server should be chrooted. Servers that host projects, (such as this one) have legit reasons to hand out user logins willy-nilly, so that volunteers can provide webmaster services, etc. These users should be chrooted, so that damage inflicted to other subsystems is minimal if the system develops a case of the rootkit. Default Debian install should make it easy/trivial to chroot a user on demand ... while still allowing that user certain types of access e.g. to web pages, etc.

Last Updated October 2003 by Linas Vepstas [email protected]
Copyright (c) 2003 Linas Vepstas.
All trademarks belong to their respective owners.

Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.1; with no Invariant Sections, with no Front-Cover Texts, and with no Back-Cover Texts. A copy of the license is included at the URL http://www.linas.org/fdl.html, the web page titled "GNU Free Documentation License".

Go Back to the Enterprise Linux(TM) Page
Go Back to the Linas' Home Page