Re: [Savannah-hackers-public] Re: [gnu.org #670138] colonialone.fsf.org Dom0 upgrade

[Michael J. Flickinger]

Jim Meyering wrote:
> Bernie Innocenti wrote:
> > On Tue, 2011-02-22 at 00:22 +0100, Jim Meyering wrote:
> >
> > > [...]
> > >
> > > Wrong comparison.
> > > Compare using fwknop-and-alt-ssh-port to agent-fwd-through-fencepost.
> > > The former is more secure.
> > Ok, I'd like to propose an entirely different solution: we already
>
> Why?
> Isn't IP restrictions + (fwknop-and-alt-ssh-port|fencepost-for-a-few)
> simple and effective enough?

I think this solution actually makes more sense than 
"fwknop-and-alt-ssh-port."  As Bernie mentioned, part of the reason this 
would help is because there's more than one machine in scope here.  Not 
to mention, that openvpn would provide a logged single point of entry, 
which, of course, would still require ssh to actually access the machines.

> > employ openvpn to access the FSF internal lan from remote clients. We
> > could setup a separate VPN for the Savannah machines.
>
> If I had to bet the house on immunity to exploit of a tool, I'd prefer
> ssh over openvpn, though not by much.  ssh is used/audited a lot more.
> fwknop is tiny and doesn't add a whole new protocol and networking.

OpenVPN wouldn't be running on Savannah though, if it's compromised, 
you'd still need to ssh into the machines in the vpn.  If fwknop, for 
example, if compromised, it's likely running as root on the machine 
you're intending to secure...

> One reason for IP restrictions is to limit vulnerability if a 0-day
> exploit appears.  How would using openvpn mitigate that?
> Actually, adding openvpn probably more than doubles what they
> call the attack surface.

I'm not sure how it does, if it's running on a different machine.

> > The SSL certificate can be password protected and would be accessed only
> > from the openvpn daemon, so it doesn't have to be readable by the user
> > account (it doesn't even need to be on the same machine).
> >
> > It seems to be both more secure and more convenient than fwknop,
> > especially when we have to deal with multiple machines. It's also not to
> > hard to setup.
> >
> >
> > --- BEGIN off topic ---
> >
> > > The TCO of SELinux for the vast majority (since F14, maybe since F13)
> > > has been zero, because most things "just work."
> > This is true only for plain desktops and trivial servers that don't
> > require any major change to the default configuration. Every time I did
> > something serious, eventually I was forced to either turn off SElinux or
> > start programming in obscure-language-for-custom-policy-definition.
>
> I think you've just agreed.
> The vast majority of users do nothing that requires them
> even to know about the existence of SELinux, much less its "policy".
>
> [ You know, we've had this conversation before.  Have you
>   tried again in the last year or so (F13 or F14)?  If there's
>   a tool that gives you particular pain wrt SELinux, look again...
>   maybe someone else has already written policy for it by now.  ]
>
> > --- END off topic ---