[Dshield] More secure default configurations?
shirkdog_list at hotmail.com
Thu Mar 24 15:55:31 GMT 2005
Well at least he can't blame OpenBSD :-)
>From: Miles Stevenson <miles at mstevenson.org>
>Reply-To: General DShield Discussion List <list at lists.dshield.org>
>To: General DShield Discussion List <list at lists.dshield.org>
>Subject: [Dshield] More secure default configurations?
>Date: Fri, 18 Mar 2005 10:43:09 -0800
>I just read a Security Focus article that has been gaining a bit of
>on Slashdot recently, titled "Linux Kernel Security, Again", by Jason
>In the article, Jason shares his opinion about Linux distributions not
>with more secure default settings, in this case default ulimit settings for
>number of allowed processes. The article can be found at:
>But who's responsibility is it to secure a computer system? Is it the OS
>vendor? The individual application vendors? The reseller? Or perhaps, the
>I don't care if you are selling a proprietary OS such as Windows, or an
>source system like RedHat or SuSe, you are still subject to the economics
>supply and demand. If you want people to use your OS (whether you want to
>paid for it or not), you have to respond with what they want.
>As infosec professionals and enthusiasts, we understand the value in the
>principle of least privilege. We know that from a security standpoint, it
>a good idea to restrict users as much as possible in order to keep their
>secure. But those of us who end up having to deal with such users directly
>(such as sysadmins and support staff) know all too well that users do not
>like being restricted. I think vendors know this too.
>At my company, it is my responsibility to properly secure the systems that
>build. If a user were to launch a successful forkbomb attack against one of
>our systems, it would be the sysadmin's responsibility to set the proper
>ulimit on the machine, not the OS vendor.
>Even personal desktops running Windows XP are ultimately the responsibility
>the owner. It is my responsibility to implement the appropriate security
>controls for my web surfing needs. It is my decision if I want to enable
>automatic logon as an Administrator or not, not Microsofts.
>Instead of trying to persuade and inform users how to better secure their
>systems, the security professionals such as Jason Miller blame the OS
>for not being secure enough, who in turn implements more restrictive
>security controls, who in turn gets blamed by the majority of the user
>community for their product not being very intuitive and easy to use.
>I realize that setting more restrictive ulimit settings by default probably
>won't impact the majority of users. I agree that it would be a good idea to
>have more restrictive default ulimit settings by default. But my point is
>that this case illustrates a reaction from the security community that I
>think is understandably instinctive, but misguided: software vendors need
>start tightening up their default settings to be more restrictive. It's
>for us to ignore the impact this will have on the user market, but not the
>All software should have the capability to be properly secured. Writing
>code and offering security functionality is the responsibility of the OS
>vendor. But configuring the security of a computer system appropriately is
>the responsibility of the system owners. Instead of blaming OS vendors for
>not implementing more secure default security configurations, how about
>persuading users that they should want more restrictive but secure
>configurations? If the majority of users demand (actually desire) more
>configurations of their systems, the laws of supply and demand will ensure
>that vendors will respond.
>Email: miles at mstevenson.org
>PGP/GPG Key ID: 329F889D767D2F63
>-------------- Sponsor Message ------------------------------------
>Join us at SANSFIRE 2005 in Atlanta!
>The Internet Storm Center Conference.
>send all posts to list at lists.dshield.org
>To change your subscription options (or unsubscribe), see:
FREE pop-up blocking with the new MSN Toolbar get it now!
More information about the list