On Sun, 11 Dec 2011 16:53:02 +0200
Alex Efros wrote:

> Hi!
> 
> On Sun, Dec 11, 2011 at 02:25:19PM +0000, Sven Vermeulen wrote:
> > > 1)  How can
> > > 	4.2.4.1. Root Logon Through SSH Is Not Allowed
> > >     increase security, if we're already using
> > > 	4.2.4.2. Public Key Authentication Only
> > >     Disabling root may have sense with password auth, but with keys it is
> > >     just useless inconvenience.
> > 
> > I read somewhere that security is about making things more inconvenient for
> > malicious people than for authorized ones.
> > 
> > For me, immediately logging in as root is not done. I want to limit root
> > access through the regular accounts on the system (with su(do)). I never had
> > the need to log on as root immediately myself.
> 
> Understood. But I still don't see how this can increase security.
> 

Defense in Depth, I disable root in >4 different ways.

shell
pam
ssh_config
securetty
suid + setcap
rbac
chattr + immutable syscall turn off

It may not help against root exploits but it makes life a little more
difficult for priv escalation.

It may take more work to iron out any diffciulties (short lived) but if
you try to imagine the exploits rather than using minimal
footprint/priviledges then you won't get that nice feeling of, hee hee
doesn't affect me, nearly so often ;-). You'd be surprised, there's
been lots of times where I've thought this is pointless and yet it's
paid off eventually.


>>5)  In my experience, while
>>	4.8.5. Review File Integrity Regularly
>>   looks like good idea, it's nearly impossible to use in Gentoo because
>>    of daily updates which change a lot of system files, so it's too hard
>>    to review aide-like tool reports and quickly detect suspicious file
>>    changes. If anyone have a good recipe how to work around this I'll be
>>    glad to learn it.


The king of this for full pc (x86 etc.) is OpenBSD, though package
updates are more work. I have NEVER had to upgrade the kernel on an
OpenBSD system due to security problems. (Only because I had disabled
ipv6 where it wasn't needed though, which re-affirms the above. I would
guess you would have said disabling ipv6 where it is not needed to be
just a hindrance and not anything to do with security and yet it
accounts for one of the only remote exploits on OpenBSD at default in
more than a decade and meant that I could leave my systems humming away,
rather than getting hot and bothered). In fact some of them could have
been left untouched untill now if it wasn't for the want to upgrade.

Of course an attacker who modifies files isn't very good these
days. Though they are the ones you may catch.

p.s. There really should be a central linux kernel security problem
site as the work of necessarily good people seems duplicated at the
moment?