On Fri, Dec 15, 2000 at 02:58:10PM -0600, Scott Dier wrote:
> * Chad '^chewie' Walstrom <chewie at wookimus.net> [001215 13:39]:
> >     1)  I don't have the source code, :. I cannot audit it's security.
> 
> http://cosm.mithral.com/
> http://www.stanford.edu/group/pandegroup/Cosm/source.html
> 
> Hrm, it still doesn't say anything.  Anyhow. 
> >     2)  It's in binary format.  Even if I had the source code, how
> 
> I hope you dont run dnetc either, then.  At least Cosm gives you a look
> at the low level stuff that they implement.

I had to look up on google what the hell 'dnetc' was...  No I don't
run the rc5 crackers.  I do run setiathome outside a chroot jail,
since I didn't take the time to learn how to do it before this week.
Rest assured, setiathome will be finding it's hat being hung in a
virtual world shortly.

> The thing about chroot jails, is that they dont stop everything.  If
> someone still gets access to your machine remotely, and somehow puts a
> staticaly linked trojan... they can still plan a awesome DDoS from your
> resources.
> 
> Sometimes, paranoia leads to getting nothing done.

Sometimes, but a little paranoia is better than none.  By this
statement, you are not suggesting that I "not" put this binary in a
chroot jail, are you?  That would be quite bold.  I highly doubt that
the folding at home project is a front, but it's possible.  

And yes, putting something in a chroot jail won't protect you from
being a DoS node.  LIDs could, however.  With LIDs, you can tie in the
Kernel Capabilities features down to the file level, meaning you can
give specific executables system-specific permissions.  If you know,
for example, that you would like to download new work packages for
setiathome at set intervals using cron, you can set up a cron job to
open up the NET capabilities to the program at that time and close
them once the application's finished it's downloads.

Yes, lots of custom hacking with perl to time everything correctly,
but it is possible.

Of course, the best security to stop DoS attacks in this case is tying
an IPCHAINS or IP Tables rule down to the file level.  Something like:

    ipchains -A output -i eth0 -p tcp -o setiathome \
            -d setiathome.server.edu 80 -j ACCEPT 

Where '-o' specifies the object to give outgoing connection permission
to.

The same patches used for LIDs could be extended into the IP filtering
code.  (Boy would that have a potential to slow down the TCP stack, or
what?!)

Anyway, enough brainstorming.  Time to install a new kernel... ;-)

-- 
Chad "^chewie, gunnarr" Walstrom <chewie at wookimus.net>
             http://www.wookimus.net/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 232 bytes
Desc: not available
Url : http://shadowknight.real-time.com/pipermail/tclug-list/attachments/20001216/cfa8b974/attachment.pgp