Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 27 Jul 2003 15:52:39 +0200
From:      Socketd <db@traceroute.dk>
To:        hawkeyd@visi.com, security@freebsd.org
Subject:   Re: suid bit files + securing FreeBSD (new program: LockDown)
Message-ID:  <20030727155239.3205a60b.db@traceroute.dk>
In-Reply-To: <20030727125136.GA6810@sheol.localdomain>
References:  <00d601c3539a$91576a40$3501a8c0@pro.sk> <20030726235710.GD4105@cirb503493.alcatel.com.au> <20030727132847.5adc6b07.db@traceroute.dk> <20030727112933.GA6135@sheol.localdomain> <20030727143600.1517c588.db@traceroute.dk> <20030727125136.GA6810@sheol.localdomain>

next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 27 Jul 2003 07:51:36 -0500
D J Hawkey Jr <hawkeyd@visi.com> wrote:

> CC'ing security@ now, since you did.

Oh sorry, didn't see that you only replied to me :-)

> Would you consider my above suggestion?

> It could certainly be installed from the ports collection, but it
> would be most useful to me (and p'raps others?) as a boot-time thang.
> Think of dedicated firewalls and routers, especially those that boot
> from custom CDs [and p'raps read floppies for "volatile"
> configuration].
> 
> In my mind, the conf could be installed as /etc/rc.whatever, and the
> program could be installed as /usr/local/etc/rc.d/whatever. In this
> way, it'd be run on boot, and could be run anytime as
> "/usr/local/etc/rc.d/whatever start", and p'raps as a cronjob, too.

Ah, good idea!

> I'm thinking of rootkits and whatnot that drop a SUID/SGID program on
> a box and force a reboot to "kick it in". Your program, by enforcing
> the"rules" in the conf, could remove the exec bits on the trojan, or
> just blow the trojan away. I realize I might be widening the scope
> here...

Hmm, if an attacker got root and installed a rootkit LockDown would be
of no help. LockDown was meant to automatically setup a secure machine
using the facilities that are already in the base system, but you gave
me an idea! LockDown could search for ALL suid and gid files and set the
permissions accordingly to the conf file, the files not listed there
would be disabled (or set to a user specified default). But then again,
if an admin installs a port with suid files and forget to add them to
the LockDown conf file, they would be disabled the next time LockDown is
executed.

I have also thought about adding these options:
1. More kernel help, so you quickly can setup a kernel:
	kern_using_RAID=""		YES if you are using raid hardware
	kern_using_SCSI=""		YES if you are using SCSI hardware
	kern_using_IPv6=""		YES if you want to use IPv6
	kern_using_proc=""		YES if you want to use /proc
	kern_NIC=""			The nic's you use.

2. Support for most of the files in /etc (and other?)

3. Give security adwise:
	1. Setting up different daemons
	2. What ports to install
	3. How to setup scripts to be used with cron and what to include in
them

> Were you to go this way, I could see where Core might consider adding
> your work into the base? I'd lobby for it.  :-)

My code in the base system...oh I don't even dare think the beautiful
thought ;-)

> > I use C++
> 
> Oh. I was hoping you'd answer "shell script" (my preference, for quick
> 'n easy modification), or "C".

Well, it could be written as a shell script, but I only know C++. If
someone want to join this project and write the shell script, I would be
happy to help with the overall design and documentation.

br
socketd



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030727155239.3205a60b.db>