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@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@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@gtalug.org
https://gtalug.org/mailman/listinfo/talk