[Dshield] More secure default configurations?

Henry Hertz Hobbit hhhobbit at comcast.net
Sun Mar 20 01:17:42 GMT 2005


On Fri, 2005-03-18 at 11:43, Miles Stevenson wrote:
> I just read a Security Focus article that has been gaining a bit
> of attention on Slashdot recently, titled "Linux Kernel Security,
> Again", by Jason Miller.  In the article, Jason shares his opinion
> about Linux distributions not coming with more secure default
> settings, in this case default ulimit settings for number of
> allowed processes. The article can be found at: 
> http://www.securityfocus.com/columnists/308
> 
> 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 user maybe? 

I appreciate your comments, but I would say that ALL of the above
are responsible for security (you omitted the SysAdmin).  I can
remember saying for years that Sun and the other Unix vendors
should ship boxes out with all the inetd services turned off.
The Linux vendors are doing that now.  Here are the responsibilities
I see each position having:

[1] The OS vendor should send the OS out with no extra services turned
on than are necessary.  All others should be turned off.  In the case
of Linux and Unix, the time has come to say goodbye to sendmail as the
default SMTP.  Allow the admin to pick their poison - whether it is
sendmail, postfix, qmail, or Exim. The vendor should NOT make it
difficult to put something other than sendmail on.  I am getting tired
of doing an OS install, then installing postfix, then removing the
sendmail program.  RedHat / Fedora and SuSE are also doing one more
thing that irks me.  On Linux, the executable files in /usr/bin and
/bin should be owned by bin, and be group bin (or another nologin
user) UNLESS they need to be owned by root.  Having them all owned
by root has irked me for years.  Yes, I could change them, but then
I would have to go through and alter all the ones like login, etcetera,
that need to be owned by root (and probably should be in either
/usr/sbin or /sbin).

[2] Application vendors are responsible for making their applications
as secure as possible.  I can remember installing a Microsoft App to
do version control.  Their default file permissions were 777 for
EVERYTHING!  I can also remember an Electrical Engineering tool from
HP named eesof that had me typing the following in the dir it was
installed in (which was NOT in /usr/local):

	cd # to the dir above eesof
	find eesof -type d -exec chmod 755 {} \;
	find eesof -type d -exec chown root {} \;
	find eesof -type d -exec chgrp staff {} \;
	for PERM in 777 775
	do
		find eesof -type f -perm $PERM -exec chmod 755 {} \;
	done
	for PERM in 666 664
	do
		find eesof -type f -perm $PERM -exec chmod 644 {} \;
	done
	find eesof -type f -exec chown bin {} \;
	find eesof -type f -exec chgrp bin {} \;
	find eesof -type l -print
	# I handled the symlinks manually

Then, I found that they had installed ghostscript IN the eesof
directory.  The sales person told the head engineer (also VP of
the company) that it would be fine.  That was when I explained to
him that Sun's OpenLook environment uses Display Postscript, and
that he would have been better off buying a PostScript printer.
That was when I discovered that ghostscript was installed wrong.
Every place there should have been a file, there was a folder (dir)
with the same name of the file in it.  Out came another shell
script:

	for DIR in a* b* c* C* # starting folder names
	do
		mv $DIR foo
		cd foo
		mv  * ..
		cd ..
		rmdir foo
	done

But ghostscript would only work for eesof, not anything else.  What
is the moral to the story?  Vendors, PLEASE hire a good competent
SysAdmin to make sure the install is CORRECT.  At least with most
modern Nixes we don't have to worry about ghostscript any more.

[3]  The harried SysAdmin is responsible for too much in my opinion.
One thing they SHOULD do is set the umask in the startup scripts in
skel for the normal users to 077, not the 002 that is the default
for Fedora in /etc/bashrc.  I know a school (University) that made
all of the students in one group, and the faculty members in
another group rather than having a separate group for each user.
At least the default umask on Solaris is 022, but the students
could all read each other's files!  They also took qmail off the
machine, and put sendmail back on.  At least they did one thing
right - in addition to all of the rsh, rexec and other services
that were already shut off, they finally shut down telnet and ftp
and forced the Windows users to use puTTY so that they could ssh
and sftp.

[4]  If the users note that the default umask is NOT 077, then
they should do it themselves, but feed back the information into
the chain.  The same applies to other things they see that are
wrong.  The SysAdmin should NOT stubbornly refuse input to
tighten down the screws, and executives all over need some
retraining to realize that the name of the game has changed,
and what was good enough yesterday is not good enough today.

In short, security is possible only if EVERYBODY does their part.
Oh yes, a reasonable ulimit should be set by the Linux OS vendors.
It should be enough to prevent a fork bomb attack, but NOT be overly
restrictive, especially to root.  If you don't want ulimits, then
turn them off.  There are other things that need to be done as well.
The harried SysAdmin may forget to do them.

HHH
-- 
Key Name:  "Henry Hertz Hobbit" <hhhobbit at comcast.net>
pub   1024D/1CC23BC0 2005-03-08 [expires: 2006-03-08]
Key fingerprint = 9CD0 839E 79C9 5E20 B97A 15A6 9AB7 484D 1CC2 3BC0





More information about the list mailing list