Promoting Linux Requires Advertising. That's What Counts.
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.
- Contains XXX remarks from Juliane Haugh regarding the nologin, the status
needs to be clarified.
- 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.
- 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.
- 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
- 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
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
the web page titled
"GNU Free Documentation License".
Go Back to the Enterprise Linux(TM) Page
Go Back to the Linas' Home Page