[prev in list] [next in list] [prev in thread] [next in thread] 

List:       annvix-dev
Subject:    Re: [dev] Package removal and rebuild status
From:       Vincent Danen <vdanen () annvix ! org>
Date:       2004-06-30 0:49:28
Message-ID: 57827042-CA2F-11D8-839F-000A9598BFB2 () annvix ! org
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


On Jun 29, 2004, at 6:40 PM, Ying-Hung Chen wrote:

>> Ok, now here's the real question.  Does/will openswan work with the 
>> 2.6 kernel?  I mean, do we ever need ipsec-tools?  Especially in 
>> light of your testing and how it doesn't seem to work with... well.. 
>> .anything?
>
> from my test, freeswan works with 2.6 kernel. and from openswan 
> website, it states:
>
> "Openswan is an implementation of IPsec for Linux. It supports kernels 
> 2.0, 2.2, 2.4 and 2.6, and runs on many different platforms, including 
> x86, ia64, mips and arm."
>
> so i guess the answer is definitely "yes"

Excellent.  Then ipsec-tools can take a hike.  I kinda like the idea of 
Annvix being able to interoperate with other systems instead of just 
itself (and Mandrake 10+).

> since i just start playing with 2.6.7, i am not too sure why most of 
> the doc refer to the ipsec-tools (racoon) all over the place, I'll 
> look into it. in the mean time, i think ipsec-tools may not be 
> necessary
>
> and as Thomas point out, openswan will integrate the crypto algorithms 
> in the new version (which defeat my bad example). so i guess openswan 
> will be my current choice =)

=)

> also, anyone uses encrypted filesystems? i used for /var/spool/mail, 
> /home paritions, but never done it for the *entire* system. Because I 
> didn't encrypt the whole system, remote reboot is possible (I just log 
> back in and mount the encrypted partition). However, if a 
> administrator have the physical access to the server and wanted the 
> FULL security (in case someone break in, and take the computer), do we 
> want to look into this case?

I have not looked into this in depth, but it makes me nervous.  
Granted, it's a fine idea, and probably pretty useful for home users 
and/or laptop users.  But on a server, I'm not so sure.

I mean, what happens if you lose your password?  Sure, this might seem 
like common sense to some, but it happens all the time.  A lost 
password could be really really *really* bad.  I think there is also a 
compromise in speed for the system, which would also have to be 
considered.

I think of it like this.  ssh keys can be redone if passwords are lost. 
  gpg keys can be revoked/replaced in the same scenario.  A user's 
password can be modified by root if a user loses it.  root's password 
can be changed by booting off a livecd and chrooting the system.

What safeguards are there if you lose the password to your encrypted 
fs?  Absolutely none.

Also, how to implement it?  Using loopback is a pretty cruddy way to do 
this, I think, and could be prone to all kinds of problems and 
performance decreases.  Better if there was something like encryption 
directly in reiserfs or in XFS or [name your FS here].  I dislike the 
idea of containers... true encryption, in the fs itself, is a better 
bet.  Does something like this exist?  (I haven't had a chance to 
really look into this because I think a well-secured system is 
easier/safer than something like this short of someone coming into your 
house/server room and taking the computer home with them).

I'm all for discussing it, but I think before we make any plans to 
implement something like this it needs to be well thought out and 
benchmarked and there has to be some sort of failsafe in case a 
password does get lost.

(And, as you stated, something would have to be done to permit 
automatic mounting of encrypted filesystems in the event of remote 
servers, automatic reboots, power outages, etc.).

-- 
Annvix - Secure Linux Server: http://annvix.org/
"lynx -source http://linsec.ca/vdanen.asc | gpg --import"
{FE6F2AFD : 88D8 0D23 8D4B 3407 5BD7  66F9 2043 D0E5 FE6F 2AFD}

["PGP.sig" (application/pgp-signature)]

_______________________________________________
dev mailing list
dev@annvix.org
http://annvix.org/mailman/listinfo/dev


[prev in list] [next in list] [prev in thread] [next in thread]