[GTALUG] Linux hardening question

[Mauro Souza]

I think OP will be the only user on the server, so chmod /etc is not that
important. If someone exploits any service and gets a shell on the box,
chmod will not help too much.

Jailing the accessible servers on a container, or a old school chroot would
be nice.

On Jun 29, 2017 10:24, "Lennart Sorensen via talk" <talk at gtalug.org> wrote:

> On Wed, Jun 28, 2017 at 07:21:55PM -0400, Anthony de Boer via talk wrote:
> > Christopher Browne via talk wrote:
> > > On 27 June 2017 at 19:53, Kevin Cozens via talk <talk at gtalug.org>
> wrote:
> > > > You may also want to "chmod 711 /etc", FWIW.
> > >
> > > That means that non-root-space applications will have no access to
> their
> > > configuration in /etc, thereby breaking services.
> >
> > Umm, no.  The x-bit is what you need to access files inside a directory,
> > so a non-root user can still access /etc/resolv.conf and so on.  Not
> > having the r-bit means you can't "read" the directory itself and get a
> > list of files in it.  So no filename autocompletion for you while you're
> > trying to cat that file!
>
> Without the r bit you can not read the contents of a file.
>
> > However, all the filenames that matter in /etc are fairly canonical and
> > not being able to "ls /etc" isn't really going to slow folk down much,
> > just unnecessarily annoy them.
>
> Yes removing the x bit would probably not be a problem, but removing
> the r bit would.
>
> > Many years ago a coworker tried "chmod 700" on /etc etc, and chmod 600 on
> > many key files, the upshot of which was that everything on the "secured"
> > firewall had to run as root and it ended up less secure.
>
> And 711 is no better.  744 might work OK though.
>
> Now if you meant chmod JUST /etc, then sure fine.  I think we all thought
> you meant recursively chmod /etc which would be a disaster.
>
> --
> Len Sorensen
> ---
> Talk Mailing List
> talk at gtalug.org
> https://gtalug.org/mailman/listinfo/talk
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://gtalug.org/pipermail/talk/attachments/20170629/c0d53513/attachment.html>