You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Nico Kadel-Garcia <nk...@gmail.com> on 2011/01/03 04:43:31 UTC
Fine and secure dining, was Re: svnadmin create and not being method agnostic
[ Changing the subject line, this has gone off the deep end, partly my fault. ]
On Sun, Jan 2, 2011 at 7:50 PM, Tony Sweeney <ts...@omnifone.com> wrote:
>
>
> -----Original Message-----
> From: Nico Kadel-Garcia [mailto:nkadel@gmail.com]
>>It's not cow. Subversion security is *goat*. Inexpensive to buy the
>>unprepared meat, but it;'s fairly gamey, risky for inexperienced
>>chefs, and raises suspicious eyebrows if anyone sees you with the big
>>hammer you need to tenderize it. But if the chef's time costs less
>>than the raw materials, some customers want it.
>
> Ahem. Subversion security is not goat. Goat is fine eating, from the Caribbean to the middle east and central and southern Asia. Subversion security is *roadkill*. At the top end, Apache security is venison; a delicacy that many would be happy to pay for or indeed to hunt themselves. At the low end, svnserve security is possum; hey, it's free, and it does the job so long as you hold your nose while you swallow. I'll leave it to others to fill in the intermediate tiers/tieren*.
Dude, I've eaten all of them. Goat is fine eating after you've hidden
the actual flavor of the goat, it's very tough meat and very gamey.
(High uric acid content.) Possum is, admittedly, even more gamey, at
least when I've had it. (Although I wasn't the cook.)
It's possible to do secure Subversion. Use svn+ssh access, disable or
block other services at the firewall, and keep it away from HTTP/HTTPS
in order to prevent UNIx or Linux client plaintext password storage.
It's just tricky and a lot of work, and you wind up having to do it
yourself due to the non-existent Subversion specific shell for
designated 'svn' users, and the lack of a CGI utility that would
support suexec operations for suexec based shell sites, and the fact
that "svnadmin hotcopy" doesn't preserve permissions or uid/gid
settings when you duplicate repositories.
Re: Fine and secure dining, was Re: svnadmin create and not being
method agnostic
Posted by Johan Corveleyn <jc...@gmail.com>.
On Thu, Jan 6, 2011 at 1:29 AM, Nico Kadel-Garcia <nk...@gmail.com> wrote:
> On Wed, Jan 5, 2011 at 2:19 PM, Les Mikesell <le...@gmail.com> wrote:
>
>> Of course you _can_ secure it. My point is that permitting ssh and
>> restricting access to ssh by itself is very likely to make your system less
>> secure (if you count on firewall protections) instead of more so. And
>> nothing that can be done in the default svn installation can fix it.
>
> It's an issue. The layers and layers of external-to-subversion hackery
> to secure any of the multiple forms of access is fairly burdensome.
> Coupled with the lack of configuration tools for the SSH key
> management, and it's a compounded problem. Alternative port use, and
> restricting a separate SSHD for external access with only a single
> user allowed and access restricted to SSH keys, it's a lot better, but
> those are extra and fairly painful steps.
>
> Mind you, compared to storing the HTTP/HTTPS passwords in clear text
> in fashions that are unstoppable by the server and is enabled by
> default in all UNIX and Linux clients, it's a 2 inch thick vault door,
Oh, come on. From the server side you can never control what I do as a
user with my password. If I find it convenient to use the same
password on facebook, there is not much you as a sysadmin can do about
it.
So if I'm on *nix, without gnome-keyring and KDE-wallet, and I decide
to ignore the warning "this will store the password in clear-text in
your homedir, are you sure?", which my sysadmin specifically
instructed me *not to do*, that's basically the same thing. Well, it's
actually vastly less severe than re-using that password for other
(non-company) services, because the password is still only in a file
that's in my homedir with permissions that make it readable only by
me.
Cheers,
--
Johan
Re: Fine and secure dining, was Re: svnadmin create and not being
method agnostic
Posted by Nico Kadel-Garcia <nk...@gmail.com>.
On Wed, Jan 5, 2011 at 2:19 PM, Les Mikesell <le...@gmail.com> wrote:
> Of course you _can_ secure it. My point is that permitting ssh and
> restricting access to ssh by itself is very likely to make your system less
> secure (if you count on firewall protections) instead of more so. And
> nothing that can be done in the default svn installation can fix it.
It's an issue. The layers and layers of external-to-subversion hackery
to secure any of the multiple forms of access is fairly burdensome.
Coupled with the lack of configuration tools for the SSH key
management, and it's a compounded problem. Alternative port use, and
restricting a separate SSHD for external access with only a single
user allowed and access restricted to SSH keys, it's a lot better, but
those are extra and fairly painful steps.
Mind you, compared to storing the HTTP/HTTPS passwords in clear text
in fashions that are unstoppable by the server and is enabled by
default in all UNIX and Linux clients, it's a 2 inch thick vault door,
Re: Fine and secure dining, was Re: svnadmin create and not being
method agnostic
Posted by Les Mikesell <le...@gmail.com>.
On 1/5/2011 1:04 PM, David Brodbeck wrote:
>
> It's possible to do secure Subversion. Use svn+ssh access,
> disable or
> block other services at the firewall,
>
>
> If ssh is permitted and you didn't personally set it up, what are
> the odds that port tunneling or ssh's built in socks proxy will
> allow access to every service behind the firewall?
>
>
> The nice thing about SSH is you can disable those things via server
> configuration. They are on by default in most distributions (and maybe
> shouldn't be) but the configuration switches to turn them off are easy
> to find.
Of course you _can_ secure it. My point is that permitting ssh and
restricting access to ssh by itself is very likely to make your system
less secure (if you count on firewall protections) instead of more so.
And nothing that can be done in the default svn installation can fix it.
--
Les Mikesell
lesmikesell@gmail.com
Re: Fine and secure dining, was Re: svnadmin create and not being
method agnostic
Posted by David Brodbeck <br...@uw.edu>.
On Mon, Jan 3, 2011 at 8:46 AM, Les Mikesell <le...@gmail.com> wrote:
> On 1/2/2011 9:43 PM, Nico Kadel-Garcia wrote:
>
>>
>> It's possible to do secure Subversion. Use svn+ssh access, disable or
>> block other services at the firewall,
>>
>
> If ssh is permitted and you didn't personally set it up, what are the odds
> that port tunneling or ssh's built in socks proxy will allow access to every
> service behind the firewall?
>
The nice thing about SSH is you can disable those things via server
configuration. They are on by default in most distributions (and maybe
shouldn't be) but the configuration switches to turn them off are easy to
find.
--
David Brodbeck
System Administrator, Linguistics
University of Washington
Re: Fine and secure dining, was Re: svnadmin create and not being
method agnostic
Posted by Nico Kadel-Garcia <nk...@gmail.com>.
On Mon, Jan 3, 2011 at 11:46 AM, Les Mikesell <le...@gmail.com> wrote:
> On 1/2/2011 9:43 PM, Nico Kadel-Garcia wrote:
>>
>> It's possible to do secure Subversion. Use svn+ssh access, disable or
>> block other services at the firewall,
>
> If ssh is permitted and you didn't personally set it up, what are the odds
> that port tunneling or ssh's built in socks proxy will allow access to every
> service behind the firewall?
It's not ideal: a dedicated shell (such as gitshell) would be
preferable, but there are intelligent tools such as gitosis for
enabling and configuring just such a service. It need only be open for
the single "svn" dedicated user that holds the SSH keys, and the
authorized_keys can be set to restrict commands usable by that SSH key
access to a single command. This is why Kerberized access to such an
svnserve service account is not workable: it's permitted operations
cannot be so limited as the SSH key technology.
It would still be somewhat better than the current setup if that user
used "rssh", but I've not personally succeeded in integrating
Subversion support into that toolkit.
Re: Fine and secure dining, was Re: svnadmin create and not being
method agnostic
Posted by Les Mikesell <le...@gmail.com>.
On 1/2/2011 9:43 PM, Nico Kadel-Garcia wrote:
>
> It's possible to do secure Subversion. Use svn+ssh access, disable or
> block other services at the firewall,
If ssh is permitted and you didn't personally set it up, what are the
odds that port tunneling or ssh's built in socks proxy will allow access
to every service behind the firewall?
--
Les Mikesell
lesmikesell@gmail.com
Re: svnadmin create and not being method agnostic
Posted by Stefan Sperling <st...@elego.de>.
On Mon, Jan 03, 2011 at 04:19:20PM -0500, Andy Levy wrote:
> On Mon, Jan 3, 2011 at 15:56, Nick <no...@codesniffer.com> wrote:
> > On Mon, 2011-01-03 at 11:49 -0500, Mark Phippard wrote:
> >> > Apologies in advance if this is covered somewhere, but can someone
> >> > explain (or point me to some references on) why using SVN w/ Apache
> >> > (HTTPS) is insecure? I've seen some references to plain text
> >> password
> >> > storage, but I don't see my password on my server. The passwords in
> >> my
> >> > svnusers files look like hashes, which makes sense because I use the
> >> > "-m" option to htpasswd2 when creating them. What am I missing?
> >>
> >> Yes, it is secure. Nico's issue is that the SVN client will allow the
> >> user to cache their password in plaintext locally in their home
> >> folder. This is only true for *nix clients though. Windows and OSX
> >> clients store the password securely.
> >
> > I see, thanks. So by "SVN client", are you referring to the command
> > line client that's provided by SVN?
> > May I ask why the *nix client stores the credentials in plain text?
> > Again, I'm open to references which explain it if this has already been
> > covered.
>
> I believe it's because there is no one standard crypto library that
> can easily be expected to exist on every *nix system. You can use
> Gnome Keyring & KDE Wallet, but you have to explicitly use that option
> on the commandline.
>
> Windows has the Win32 Crypto API built in, and OS X has Keychain. You
> know they'll always be there and available, so they're used. IIRC,
> Windows was the first to get the crypto for stored passwords, then OS
> X in SVN 1.4.
There's an FAQ entry on this, too:
http://subversion.apache.org/faq.html#plaintext-passwords
Stefan
Re: svnadmin create and not being method agnostic
Posted by Andy Levy <an...@gmail.com>.
On Mon, Jan 3, 2011 at 15:56, Nick <no...@codesniffer.com> wrote:
> On Mon, 2011-01-03 at 11:49 -0500, Mark Phippard wrote:
>> > Apologies in advance if this is covered somewhere, but can someone
>> > explain (or point me to some references on) why using SVN w/ Apache
>> > (HTTPS) is insecure? I've seen some references to plain text
>> password
>> > storage, but I don't see my password on my server. The passwords in
>> my
>> > svnusers files look like hashes, which makes sense because I use the
>> > "-m" option to htpasswd2 when creating them. What am I missing?
>>
>> Yes, it is secure. Nico's issue is that the SVN client will allow the
>> user to cache their password in plaintext locally in their home
>> folder. This is only true for *nix clients though. Windows and OSX
>> clients store the password securely.
>
> I see, thanks. So by "SVN client", are you referring to the command
> line client that's provided by SVN?
> May I ask why the *nix client stores the credentials in plain text?
> Again, I'm open to references which explain it if this has already been
> covered.
I believe it's because there is no one standard crypto library that
can easily be expected to exist on every *nix system. You can use
Gnome Keyring & KDE Wallet, but you have to explicitly use that option
on the commandline.
Windows has the Win32 Crypto API built in, and OS X has Keychain. You
know they'll always be there and available, so they're used. IIRC,
Windows was the first to get the crypto for stored passwords, then OS
X in SVN 1.4.
Re: svnadmin create and not being method agnostic
Posted by Nico Kadel-Garcia <nk...@gmail.com>.
On Fri, Jan 7, 2011 at 11:43 AM, Les Mikesell <le...@gmail.com> wrote:
> On 1/4/2011 8:25 PM, Nico Kadel-Garcia wrote:
>>
>> This is a very large and longstanding issue for me and others, and has
>> led to clients of mine rejecting Subversion outright. And it looks
>> like a legacy of Subversion's re-implementation of CVS, described as
>> "CVS done right". CVS security was even worse.
>
> I'd say instead that it looks like a lack of a suitable cross-platform
> security library - or more specifically a lack of a suitable OS facility in
> Linux to manage per-user application passwords.
No, the problem is more fundamental. This lack was not ever a good
excuse to enable plain-text password storage, especially as default
behavior. That's pretty clearly a CVS legacy, and it's rooted in the
idea that "you *must* be able to trust your local machine!!!!". This
remains blatantly false in these days of NFS shared home directories,
backup tapes, data center installed hosts managed by cage monkeys,
stolen laptops and servers, and zombie hosts roaming local networks
(all of which I've had to deal with professionally).
Adding sophisticated encryption capabilities on the host side fixes
*nothing* as long as client behavior, especially default client
behavior, allows such password storage. Approaches such as SSL key
access for https://, or SSH key access for svn+ssh:// access, is
workable. But even svn+ssh:// access presents issues because it's
layered on top of a natively unsecurable svnserve daemon
implementation. And there just aren't graceful toolkits published for
managementn of SSL keys or SSH keys for Subversion.
In fact, I'm talking to a vendor about that deficit next week, and
trying to encourage them to implement such key management as part of
their security tool suite. Wish me luck on that conversation.
Re: svnadmin create and not being method agnostic
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
Les Mikesell wrote on Fri, Jan 07, 2011 at 10:43:58 -0600:
> On 1/4/2011 8:25 PM, Nico Kadel-Garcia wrote:
>>
>> This is a very large and longstanding issue for me and others, and has
>> led to clients of mine rejecting Subversion outright. And it looks
>> like a legacy of Subversion's re-implementation of CVS, described as
>> "CVS done right". CVS security was even worse.
>
> I'd say instead that it looks like a lack of a suitable cross-platform
> security library - or more specifically a lack of a suitable OS facility
> in Linux to manage per-user application passwords.
>
If anyone has a weekend to spare, please take the time to write glue
code that connects svn_auth.h with some crypto library: 'gpg -c' or
'openssl enc' or GPGME or some other library.
The starting point on svn's side is the 'provider' interface in svn_auth.h.
> --
> Les Mikesell
> lesmikesell@gmail.com
>
Re: svnadmin create and not being method agnostic
Posted by Les Mikesell <le...@gmail.com>.
On 1/4/2011 8:25 PM, Nico Kadel-Garcia wrote:
>
> This is a very large and longstanding issue for me and others, and has
> led to clients of mine rejecting Subversion outright. And it looks
> like a legacy of Subversion's re-implementation of CVS, described as
> "CVS done right". CVS security was even worse.
I'd say instead that it looks like a lack of a suitable cross-platform
security library - or more specifically a lack of a suitable OS facility
in Linux to manage per-user application passwords.
--
Les Mikesell
lesmikesell@gmail.com
Re: svnadmin create and not being method agnostic
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
Nico, please stop saying "I don't like X" everywhere.
Stefan Sperling wrote on Wed, Jan 05, 2011 at 11:09:06 +0100:
> On Tue, Jan 04, 2011 at 09:25:11PM -0500, Nico Kadel-Garcia wrote:
> > This is a very large and longstanding issue for me and others, and has
> > led to clients of mine rejecting Subversion outright. And it looks
> > like a legacy of Subversion's re-implementation of CVS, described as
> > "CVS done right". CVS security was even worse.
>
> Whenever you bring this up (and you do that *a lot*), you always gloss
> over improvements made since. Namely the default behaviour of asking
> the user for consent before saving a password in plaintext, and the
> addition of gnome-keyring and kwallet password stores with encryption.
> Note that the gpg-agent branch will also get another chance after all.
>
> And yes, I know that none of these apply to RHEL4 systems your clients are
> using, but that's beside the point.
>
> I'd be glad if you mentioned these improvements when telling others about
> this misfeature (yes, I also think it was wrong, but there was no better
> alternative at the time), at least somewhere in the fine print.
> Otherwise you make it sound as if the project didn't care, which isn't true.
>
> Thanks,
> Stefan
Re: svnadmin create and not being method agnostic
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
Nice, please stop saying "I don't like X" everywhere.
Stefan Sperling wrote on Wed, Jan 05, 2011 at 11:09:06 +0100:
> On Tue, Jan 04, 2011 at 09:25:11PM -0500, Nico Kadel-Garcia wrote:
> > This is a very large and longstanding issue for me and others, and has
> > led to clients of mine rejecting Subversion outright. And it looks
> > like a legacy of Subversion's re-implementation of CVS, described as
> > "CVS done right". CVS security was even worse.
>
> Whenever you bring this up (and you do that *a lot*), you always gloss
> over improvements made since. Namely the default behaviour of asking
> the user for consent before saving a password in plaintext, and the
> addition of gnome-keyring and kwallet password stores with encryption.
> Note that the gpg-agent branch will also get another chance after all.
>
> And yes, I know that none of these apply to RHEL4 systems your clients are
> using, but that's beside the point.
>
> I'd be glad if you mentioned these improvements when telling others about
> this misfeature (yes, I also think it was wrong, but there was no better
> alternative at the time), at least somewhere in the fine print.
> Otherwise you make it sound as if the project didn't care, which isn't true.
>
> Thanks,
> Stefan
Re: svnadmin create and not being method agnostic
Posted by Stefan Sperling <st...@elego.de>.
On Tue, Jan 04, 2011 at 09:25:11PM -0500, Nico Kadel-Garcia wrote:
> This is a very large and longstanding issue for me and others, and has
> led to clients of mine rejecting Subversion outright. And it looks
> like a legacy of Subversion's re-implementation of CVS, described as
> "CVS done right". CVS security was even worse.
Whenever you bring this up (and you do that *a lot*), you always gloss
over improvements made since. Namely the default behaviour of asking
the user for consent before saving a password in plaintext, and the
addition of gnome-keyring and kwallet password stores with encryption.
Note that the gpg-agent branch will also get another chance after all.
And yes, I know that none of these apply to RHEL4 systems your clients are
using, but that's beside the point.
I'd be glad if you mentioned these improvements when telling others about
this misfeature (yes, I also think it was wrong, but there was no better
alternative at the time), at least somewhere in the fine print.
Otherwise you make it sound as if the project didn't care, which isn't true.
Thanks,
Stefan
Re: svnadmin create and not being method agnostic
Posted by Nico Kadel-Garcia <nk...@gmail.com>.
On Mon, Jan 3, 2011 at 3:56 PM, Nick <no...@codesniffer.com> wrote:
> On Mon, 2011-01-03 at 11:49 -0500, Mark Phippard wrote:
>> > Apologies in advance if this is covered somewhere, but can someone
>> > explain (or point me to some references on) why using SVN w/ Apache
>> > (HTTPS) is insecure? I've seen some references to plain text
>> password
>> > storage, but I don't see my password on my server. The passwords in
>> my
>> > svnusers files look like hashes, which makes sense because I use the
>> > "-m" option to htpasswd2 when creating them. What am I missing?
>>
>> Yes, it is secure. Nico's issue is that the SVN client will allow the
>> user to cache their password in plaintext locally in their home
>> folder. This is only true for *nix clients though. Windows and OSX
>> clients store the password securely.
>
> I see, thanks. So by "SVN client", are you referring to the command
> line client that's provided by SVN?
> May I ask why the *nix client stores the credentials in plain text?
> Again, I'm open to references which explain it if this has already been
> covered.
This is a very large and longstanding issue for me and others, and has
led to clients of mine rejecting Subversion outright. And it looks
like a legacy of Subversion's re-implementation of CVS, described as
"CVS done right". CVS security was even worse.
Re: svnadmin create and not being method agnostic
Posted by Nick <no...@codesniffer.com>.
On Mon, 2011-01-03 at 11:49 -0500, Mark Phippard wrote:
> > Apologies in advance if this is covered somewhere, but can someone
> > explain (or point me to some references on) why using SVN w/ Apache
> > (HTTPS) is insecure? I've seen some references to plain text
> password
> > storage, but I don't see my password on my server. The passwords in
> my
> > svnusers files look like hashes, which makes sense because I use the
> > "-m" option to htpasswd2 when creating them. What am I missing?
>
> Yes, it is secure. Nico's issue is that the SVN client will allow the
> user to cache their password in plaintext locally in their home
> folder. This is only true for *nix clients though. Windows and OSX
> clients store the password securely.
I see, thanks. So by "SVN client", are you referring to the command
line client that's provided by SVN?
May I ask why the *nix client stores the credentials in plain text?
Again, I'm open to references which explain it if this has already been
covered.
Nick
Re: svnadmin create and not being method agnostic
Posted by Mark Phippard <ma...@gmail.com>.
On Mon, Jan 3, 2011 at 11:09 AM, Nick <no...@codesniffer.com> wrote:
> On Sun, 2011-01-02 at 22:43 -0500, Nico Kadel-Garcia wrote:
>
>> It's possible to do secure Subversion. Use svn+ssh access, disable or
>> block other services at the firewall, and keep it away from HTTP/HTTPS
>> in order to prevent UNIx or Linux client plaintext password storage.
>
> Apologies in advance if this is covered somewhere, but can someone
> explain (or point me to some references on) why using SVN w/ Apache
> (HTTPS) is insecure? I've seen some references to plain text password
> storage, but I don't see my password on my server. The passwords in my
> svnusers files look like hashes, which makes sense because I use the
> "-m" option to htpasswd2 when creating them. What am I missing?
Yes, it is secure. Nico's issue is that the SVN client will allow the
user to cache their password in plaintext locally in their home
folder. This is only true for *nix clients though. Windows and OSX
clients store the password securely.
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
Re: svnadmin create and not being method agnostic
Posted by Nick <no...@codesniffer.com>.
On Sun, 2011-01-02 at 22:43 -0500, Nico Kadel-Garcia wrote:
> It's possible to do secure Subversion. Use svn+ssh access, disable or
> block other services at the firewall, and keep it away from HTTP/HTTPS
> in order to prevent UNIx or Linux client plaintext password storage.
Apologies in advance if this is covered somewhere, but can someone
explain (or point me to some references on) why using SVN w/ Apache
(HTTPS) is insecure? I've seen some references to plain text password
storage, but I don't see my password on my server. The passwords in my
svnusers files look like hashes, which makes sense because I use the
"-m" option to htpasswd2 when creating them. What am I missing?
Best regards,
Nick