Re: [gentoo-security] Advice about security solution

[Nathanael Hoyle]

Anders Bruun Olsen wrote:
> On Tue, Nov 08, 2005 at 04:47:49PM -0600, Nathanael Hoyle wrote:
>
>>grsecurity does offer several things that I would look into here,
>>notably the things dealing with restricting users to only see their own
>>processes and the like.  In general though, you need to be careful about
>>the security basics:
>
>
> Ahh yes, I remember that from playing around with grsecurity some years
> back. That would be very nice to have on my server.
>
>
>>1) Don't run *anything* setuid root that you don't trust 100%.  Even
>>then, avoid it if possible.
>
>
> I am fairly certain I don't run anything at all setuid.
>
>
>>2) Don't use a global 'nobody' account for daemons (as this allows one
>>daemon running as nobody to compromise another one if compromised).  Use
>>separate uids/gids for each daemon process and make sure they have
>>minimal priviledges to run.
>
>
> I use the default Gentoo accounts for daemons - fairly certain none of
> them use "nobody". I may be wrong?
>

Can't answer that question for all gentoo ebuilds.  There are probably
some that do.  I haven't run all of the daemons that you are running,
but rather than assume, check them out individually.  As one example, I
was dismayed to realize when I emerged pdns that by default it just runs
root.  I manually added a user and group for pdns and modified the
config to run as those users after binding the port initially (since
port 53 is priviledged).  I'd verify user id's for each daemon.
>
>>3) Chroot jail daemon processes wherever possible.
>
>
> Hmm.. any good guides or pointers to get Apache, MySQL, Postfix,
> Courier-imap, rsyncd, ventrilo, cs-server, zope and so on to run in
> jails?
>
As another poster has mentioned, mod_chroot for apache is worth looking
into.  rsyncd on gentoo comes with options to chroot in the conf.d as I
recall.  Postfix is quite happy to chroot after setting a config option
as long as the jail is set up properly.  The docs on postfix.org go into
this setup pretty carefully.

>
>>4) Consider a shell for use with ssh which allows for restricting users
>>to their home dirs (a la jail-shell).
>
>
> That's a very good idea, only they still need to be able to start their
> programs as they are used to. I can't seem to find jail-shell anywhere.
> Is it just a concept for configuring i.e. Bash or is it actually
> available somewhere?

Googling "jail shell" turns up several different shells designed for this.
>
>
>>5) Log everything possible about user logins and commands.  Consider
>>moving logs to a second system on a regular basis to avoid potential log
>>compromises.
>
>
> Unfortunately I don't have a second system to move logs to, but I can
> see why it would be a very good idea.
>
>
>>6) Deny remote root login via ssh.  Further consider using
>>public/private key pair authentication for ssh.
>
>
> All Linux installations with sshd running I have ever setup (quite a
> few) have had root-login via ssh blocked :).
>
>
>>How secure you want to be is up to you in the end.  vservers, while
>>nice, are usually not required if you are diligent about the basics.
>
>
> I see your point - if I get grsecurity up and running, do sensible
> configurations and jail as many processes as possible I should be fine.
> And anyway, this isn't exactly Pentagon or NASA - my server does not
> hold any secrets worth breaking into, so the biggest threat is likely to
> be scriptkiddies who should be easily twarted by sensible configuration,
> grsec, jails and up-to-date program versions.
>
> Thanks!
>

Good luck,
-- 
Nathanael Hoyle
Systems and Networking
Speed Express Networks, LLC
nhoyle@××××××××××××.net
432.837.2811

-- 
gentoo-security@g.o mailing list