[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Savannah-hackers-public] Re: [ #670138]

From: Michael J. Flickinger
Subject: Re: [Savannah-hackers-public] Re: [ #670138] Dom0 upgrade
Date: Tue, 22 Feb 2011 09:16:23 -0500
User-agent: Waffles

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

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 ---

reply via email to

[Prev in Thread] Current Thread [Next in Thread]