All Fluff

Posted Jun 6, 2002 17:51 UTC (Thu) by Shamgar (guest, #1356) [Link]

I think your primary problem came from the title. In the future, I'd encourage you to choose something more reflective of the content so that reader expectations fall in line with what you are actually going to give them.

If, for example, you'd described it the way you did in this post I'd have read it with a completely different mindset and would not have been disappointed. ;-)

Posted Jun 6, 2002 20:57 UTC (Thu) by AnswerGuy (guest, #1256) [Link]

Scott, I appreciate your candor, and the fact that you were alert enough post a follow-up to my comments. I can appreciate that this was a press release that was intended or a non-technical audience, and that it's publication here was inappropriate. As a fairly well know Linux sysadmin, writer, teacher and consultant I can comment on the technical points that you've made with some confidence. You're also welcome to contact me offline if you'd like to engage in a more detailed discussion about the specifics of Linux security. I'm JimD at http://www.starshine.org

While strong passwords are still a fundamental of "best practice" they haven't been the primary cause of intrusions on Linux systems. The most common intrusion vectors continue to be exploitable software bugs in privileged code (mostly in network service daemons). These days it seems that BIND has taken the top spot from sendmail for being most frequently exploited. There are a few PAM modules that can be used to enforce password strength policies (especially while passwords are being set or changed). We could probably write some additional ones.

Password expiry schemes are largely irrelevant to normal security --- they alienate users without measurable benefit and I've routinely seen users go to great lengths to "trick" the expiry and tracking software into allowing them to repeatedly re-use "their" passwords; or they'll be forced to write down their password and store it "in a safe place" because the expiry of a password always occurs when the user is busy with their real work.

By far the greatest risk in user/account passwords today is simply in the sheer number of them that are required by moderately active computer users. For example, consider the password you used to log into this site and post your response; was it strong and completely unique or did you use a variant of some other password from one of your other accounts? [I'll admit that I use similar passwords for most of my "public web" personae --- from here, and slashdot and my subscription account on The Wall Street Journal.] Passwords being shared among accounts in different administrative domains is the primary modern threat to their integrity. A cracker who gets into LWN or slashdot's web servers can gain usernames, passwords and IP addresses with which they are VERY LIKELY to compromise a statistically significant number of other accounts, from which they can glean more info.

This problem is inherent in allowing user selection of passwords.

Unfortunately it may be the case that no human usable passwords will be sufficient in the near future. I'm not going to suggest alternatives in this forum. Suffice it to say that we need to look beyond passwords for the authentication models of the future. For the present we probably needn't focus much on password security --- other than an ongoing effort to educate users and provide some minimal enforcement on pass phrase strength.

Regarding firewalls: iptables is sufficient for most applications. I don't see advantages to the commercial offerings in this arena. The major issue here is that most users in most organizations today are not willing to tolerate uniform, strict use of application layer proxies. They want to "browse" the web and they don't want to hear that Javascript this and Java that, and various plug-ins, etc are not supported through a given organization's firewall. The easiest way through a firewall is to have one of the authorized users on the inside pop open the door and drag the miscreant code in.

A better approach would be to isolate the public browsing from the local intranet applications use --- so there's a quarantine. Basically any attempt to access "outside" sites should bring up a browser that's running remotely on a sacrificial system; such that a compromise of the sacrificial system doesn't constitute any access to the internal workstations or servers. Unfortunately nobody seems to even be attempting this approach. Simple identity based authorization systems (UNIX/Linux, NT/W2K, VMS and Netware, etc) are arguably not going to protect our systems from a subverted program or "socially engineered" user.

Regarding Encryption: Where would we start! The biggest problem with PGP and GNUPG is that no one is using them. There is no corporate buy-in. If a number of major corporations and/or government agencies instituted a policy that all "official" e-mail from all of their employees was to be GPG signed, and added a support mechanism (e.g. a webservice application) for verifying the keys of their employees; then we'd have a chance. As it is, only a few dedicated cybergeeks and cryptopunks even have GPG keys and usage among them is spotty at best.

Add to that the problem posed by other media. For example, how would I sign this posting? How would you verify my signature on it? It may seem like a spurious example, but consider that an ever increasing amount of our WORK (real work, as it our jobs) is done through web forms. SSL client certificates are not nearly as widespread nor nearly as easy to use as GPG/PGP keys; and the key management for SSL client certs is abysmal. [A promising idea was to have local browsers configured to connect to local daemon proxies --- have the local proxy act as the SSL engine and certificate "wallet" or agent; so that all browsers in use by a given user would share the same keys, this might be extended for cases where users are "apartmented" at different workstations from day to day].

Regarding MACs: The various patches you mention (LIDS, GRsecurity, et al) are interesting. There are several others (like Samhain, and Medusa DS9). None of them is provided in major mainstream Linux distributions. This relegates them to use by dedicated security geeks and dilletante nerds (such as I am). Eventually some of them or some of their features will be available (probably as options) in some future version of Red Hat, S.u.S.E. etc. (Several of these are partially available as Debian packages, though there isn't an initial installation option for them and they aren't fully integrated with the rest of the distribution. It is more likely that LIDS or GRsecurity will find use in specialized, dedicated server bundles --- not general purpose distributions. However, most companies show a decided preference to use GP distributions (often "standardizing" on Red Hat) due to management (rather than purely technical) concerns.

It seems likely that Linux 2.6 (the kernel) will include filesystem ACL support. This will probably be touted as a great boon for Linux security. Unfortunately support for ACLs has not been shown to have any benefit to overall system security. The fact is that most compromises involve a subverted user or process --- that user or process then has access to ALL resources of the associated UID; making ACLs irrelevant. However ACLs do signficantly increase administrative complexity and further increase the probability that hurried and harried sysadmins will apply blanket permissions grants for expediency. Auditing ACL based systems is about an order of magnitude more difficult than auditing a system in which filesystem level ACLs are not used.

You mention Snort in passing, I'll take that as a reference to IDS (host and network) and just say that Snort is only as good as your isolation and host policy definitions. For example, if you have a system which is supposed to be a dedicated NTP/DNS server then you want to create a Snort rule to alert you any time ANY traffic other than NTP (from specific time server peers) and DNS and (possibly) SSH (from VERY specific administrative hosts) is seen going to or coming from that server. If you add an SNMP agent to that server, you have to update your Snort rules with the appropriate list of NMS addresses. Combining Snort rules with active countermeasures (forcing the system that's violating policy to shutdown through a remote power switch, etc) must be done with extreme caution (if it is to be done at all). Whenever one considers automated countermeasures one must also consider how they might be used for a DoS (denial of service) or how they might be misdirected and used as a weapon to attack an innocent bystander.

For host file integrity management I'd recommend AIDE (the free re-implementation of tripwire). I'd also recommend installing one additional one from among many that are available (or writing a small custom one in Python, PERL or C). Samhain also has a very nice file integrity system. For critical servers I suggest two different ones; statically linked. (Belts and suspenders, not two belts, and not two pairs of suspenders; diversity is required).

By far my favorite file integrity system is a write-protected backup tape containing a comprehensive tar of the system, and an LNX-BBC (bootable business card) or Tom's Root/Boot (floppy). tar dzf /dev/st0 is my friend.

The problem with security under Linux is NOT a dearth of tools or features. The major problem is that there are way too few people who have the compination of time, training and inclination/motivation to configure their systems, monitor them and keep them up-to-date.

In this sense I understand that your article is attempting to address the problem by appealing to the people who set policies and provide the funding and management that is ultimately needed. I quibble with your comments about security being about "control" (I like to say that security is the enforcement of policy; policies are requirements that relate to the availability, confidentiality, and/or the integrity of computing resources; and that all security efforts must be cast in the context of a greater risk analysis and recovery planning effort). However, I understand what you're trying to do.

(Of course I also understand that you want these managers to purchase Cylant products and services).