Re: LFS Paper on Secure Servers

Hello,

I must agree with Emmanuel that grsecurity is generally a good thing even if 
used without ACLs. Only enabled in kernel (without sysctl function ofcourse) 
it detected and prevented most of recent exploits (tested!). For particular 
system it would be great as it enforces many chroot restrictions, like:
- mouns
- double chroots
- mknods
- chmod to suid/sgid
- protects outside processes

Beside these there is also additional logging functionality, various exec 
restrictions (stuff that most exploits use), resource randomizations 
(including PIDs) which prevent attacker's predictions etc.

Tripwire: 
instead of Tripwire you could use Aide:
http://www.cs.tut.fi/~rammer/aide.html
which "is a free replacement for Tripwire. It does the same things as the 
semi-free Tripwire and more." (text extracted from their site)

Filesystem:
I (personally of course) prefer reiserfs (v3) to ext3 as it feels more robust 
and I (personally and at a company) never had problems with it.

Also there is a newer version of Bind.

Otherwise it (paper) is a fine piece of information to improve 
security-consciousness of administrators and also a detailed HOWTO to support 
it right away.


Best regards,
Bostjan


On Saturday 01 of May 2004 23:16, Bruce Dubbs wrote:
> EC wrote:
> >Great job. Very interesting and useful. I will probably test it in a few
> >weeks for my own environement. I no security expert, though.
>
> Thanks for the feedback.
>
> >I do have small comments/questions/suggestions..
> >1) The use of sendmail as an MTA .. since it is secure oriented, isn't is
> >more interesting to put postfix or qmail instead ?
>
> Possibly.  I'm more familiar with sendmail and I wanted to use the same
> MTA as our other systems.
>
> >2) Going to nALFS for the build will be great. I am newbie to LFS, but
> > have already built dozens of LFS with it. It works great, profiles are
> > quick to write, easy to maintain/change.
>
> I'm not sure that nALFS is appropriate for this because I make several
> changes to the 'stock' LFS.  It may be possible to do that and go back
> and modify the nALFS build.  I'll look at that when I get the chance.
>
> >3) isn't it interesting to use grsecurity in such environement ? Again,
> > I'm no expert, but building such an security oriented system with
> > grsecurity and a well desgined ACL seems useful.
>
> This is a possibility too.  However the paper was written from a
> relatively mainstream perspective.  As I said in the risk analysis, not
> every possible security component is needed for the threat.  Also, since
> it is a dedicated system with no normal users, ACLs seems to be overkill
> for this specific server.  They may be appropriate for other types of
> servers.
>
> You bring up some great points for me to consider.  Thanks again.
>
>   -- Bruce


-- 
http://linuxfromscratch.org/mailman/listinfo/lfs-security
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page