You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by "Perry E. Metzger" <pe...@piermont.com> on 2004/02/12 22:24:15 UTC
a few nits setting up svn...
Just set up a subversion repository with the notion it would be used
in production by a significant group of people for the first time. In
doing that, I noticed a few things I hadn't payed attention to before.
1) The template hooks don't mention anything about the directory that
the hooks will be executed in, or the path that will be in effect
when they run. This is annoying.
2) As a side effect of that, there is no error log that is kept for
failures when running hooks. That means it is hard to debug the
fact that you didn't realize that you had to
/put/in/the/path/to/the/thing in the hook script.
3) There doesn't seem to be any documentation on appropriate
permissions to give the repository parts. I'm using the svn+ssh
access method, and right now I'm running with all the svn users in
a group "svn" that can write everything under /svn, but surely this
is overkill.
4) As an aside, it would be neat if one could make the ra_svn goo
operate suid "svn" or something similar, so that the repository
could be writable only to "svn" and accidents could be avoided.
--
Perry E. Metzger perry@piermont.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: a few nits setting up svn...
Posted by kf...@collab.net.
"Perry E. Metzger" <pe...@piermont.com> writes:
> 1) The template hooks don't mention anything about the directory that
> the hooks will be executed in, or the path that will be in effect
> when they run. This is annoying.
Thanks, Perry. I've fixed this omission in r8637. As it's just a doc
change, we should be able to get it into 1.0.
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: a few nits setting up svn...
Posted by "Perry E. Metzger" <pe...@piermont.com>.
Simon Kitching <si...@ecnetwork.co.nz> writes:
> On Fri, 2004-02-13 at 14:59, Perry E. Metzger wrote:
>> Er, unfortunately, for good or ill, many people need to use
>> ssh. Sometimes this is simple good security sense -- you want to avoid
>> opening additional attack vectors for a machine.
>>
>> Given that, what might I be able to do to tighten down the on-machine
>> security without adding another bunch of code to audit talking
>> off-machine?
>
> The SVN book discusses at length exactly how to provide secure remote
> svn access.
>
> See: http://svnbook.red-bean.com/html-chunk/ch06.html
> and particularly: http://svnbook.red-bean.com/html-chunk/ch06s03.html
Yes, and I'm using such a method: svn+ssh.
Unfortunately it does not do quite what I want. Also, don't tell me
that we have to run "svnserver", since that really isn't the answer
here for our project.
Perry
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: a few nits setting up svn...
Posted by Simon Kitching <si...@ecnetwork.co.nz>.
On Sat, 2004-02-14 at 04:05, Simon Kitching wrote:
> On Fri, 2004-02-13 at 14:59, Perry E. Metzger wrote:
> > Er, unfortunately, for good or ill, many people need to use
> > ssh. Sometimes this is simple good security sense -- you want to avoid
> > opening additional attack vectors for a machine.
> >
> > Given that, what might I be able to do to tighten down the on-machine
> > security without adding another bunch of code to audit talking
> > off-machine?
>
> The SVN book discusses at length exactly how to provide secure remote
> svn access.
>
> See: http://svnbook.red-bean.com/html-chunk/ch06.html
> and particularly: http://svnbook.red-bean.com/html-chunk/ch06s03.html
and http://svnbook.red-bean.com/html-chunk/ch06s05.html, which talks
about file permissions...
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: a few nits setting up svn...
Posted by Simon Kitching <si...@ecnetwork.co.nz>.
On Fri, 2004-02-13 at 14:59, Perry E. Metzger wrote:
> Er, unfortunately, for good or ill, many people need to use
> ssh. Sometimes this is simple good security sense -- you want to avoid
> opening additional attack vectors for a machine.
>
> Given that, what might I be able to do to tighten down the on-machine
> security without adding another bunch of code to audit talking
> off-machine?
The SVN book discusses at length exactly how to provide secure remote
svn access.
See: http://svnbook.red-bean.com/html-chunk/ch06.html
and particularly: http://svnbook.red-bean.com/html-chunk/ch06s03.html
Regards,
Simon
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: a few nits setting up svn...
Posted by Brian Mathis <bm...@directedge.com>.
Perry E. Metzger wrote:
>Luis Malheiro <lu...@rerum.com.br> writes:
>
>
>>Well, if I can't use https://, I would use svn:// tunneled through a
>>SSH connection... Am I missing something on this approach?
>>
>>
>Not much. That's what I'm trying to use.
>
>However, right now that requires that I leave the repository group
>writable for all the users. They might accidently damage it as a
>result.
>
>I'd rather make the repository owned by a particular account or group
>and have a suid or sgid executable deal with preventing accidents.
>
>Perry
>
>
svn:// tunneled through ssh is NOT what you are trying to use! You are
trying to use svn+ssh://, which should probably really be called
file+ssh://. svn+ssh:// uses direct file access, svn:// does not.
Using svnserve via ssh will redirect ports from a local machine to the
remote machine, over the encrypted link. THIS IS NOT AT ALL THE SAME AS
svn+ssh://!
--
Brian Mathis
http://directedge.com/b/
Re: a few nits setting up svn...
Posted by "Perry E. Metzger" <pe...@piermont.com>.
Luis Malheiro <lu...@rerum.com.br> writes:
> Well, if I can't use https://, I would use svn:// tunneled through a
> SSH connection... Am I missing something on this approach?
Not much. That's what I'm trying to use.
However, right now that requires that I leave the repository group
writable for all the users. They might accidently damage it as a
result.
I'd rather make the repository owned by a particular account or group
and have a suid or sgid executable deal with preventing accidents.
Perry
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: a few nits setting up svn...
Posted by Luis Malheiro <lu...@rerum.com.br>.
Well, if I can't use https://, I would use svn:// tunneled through a SSH
connection... Am I missing something on this approach?
Luis
Perry E. Metzger wrote:
>Ben Collins-Sussman <su...@collab.net> writes:
>
>
>>Perry E. Metzger wrote:
>>
>>
>>
>>>Er, unfortunately, for good or ill, many people need to use
>>>ssh. Sometimes this is simple good security sense -- you want to avoid
>>>opening additional attack vectors for a machine.
>>>Given that, what might I be able to do to tighten down the on-machine
>>>security without adding another bunch of code to audit talking
>>>off-machine?
>>>
>>>
>>SSH isn't the only "safe" way to access a computer.
>>
>>
>
>That's not the point. Good security policy says that every program is
>buggy, and you thus want to rely on as few of them as possible. That's
>sometimes called "aperture narrowing" by those of us who do security
>work professionally (like me).
>
>Most break ins are not caused by problems in protocols or failures to
>encrypt -- they're caused by bugs in programs (like buffer overflows)
>and problems with configurations.
>
>Fewer services listening means fewer ways to break in and fewer
>systems to audit.
>
>
>
>>One solution is to use apache as your svn server, with SSL. Clients
>>access via https://.
>>
>>
>
>Some people prefer not to do this. Apache, for instance, is a very
>large program compared to ssh, and is much harder to audit. Also, if
>you already have ssh running on the box, you might not want to have to
>add a second service if you can avoid it. See above.
>
>Really, what I'm looking for is to make the access method to the
>repository SUID to an "svn" account and get to it over ssh. That means
>that the developers may have a potential way to break in to the svn
>account if there are bugs in the access program, but I'm not that
>concerned about that -- the main purpose is to keep them from
>accidently damaging the repository rather than to provide "real"
>security here. We mostly trust the developers and just want to stop
>accidents.
>
>However, we don't trust the wider world and would like to keep the
>machine otherwise as tied down as possible -- which means ssh access
>only.
>
>
>
>>I'm just brainstorming here.
>>
>>
>
>As I said, the easiest thing of all is probably the 30 lines of code
>needed to make the local access method successfully use suid. It
>should probably just open the files it needs, record the real user ID,
>and drop privs. Alternatively, given that we're talking suid "svn" and
>not suid root, it may be sufficient just to record the real user ID so
>that the right user is recorded in the logs etc...
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: a few nits setting up svn...
Posted by Travis P <sv...@castle.fastmail.fm>.
On Feb 13, 2004, at 12:59 PM, Garrett Rooney wrote:
> Perry E. Metzger wrote:
>
>> Brian Mathis <bm...@directedge.com> writes:
>>> The point is that there are already TWO other options that will allow
>>> you to reach the goal you want. 1 is apache, and 2 is svnserve.
>>> Using these requires ZERO code changes to svn. If apache doesn't
>>> meet
>>> your needs, then fine, use svnserve over ssh.
>> How about I drop using svn instead.
>> Actually, I won't do that -- but please bear in mind that ignoring
>> people's needs doesn't encourage people to use a program.
>> So anyway, explain to me exactly how it is that svn+ssh works. What
>> exactly is being invoked over the ssh connection? I was under the
>> impression it WAS svnserve, just being run to stdout instead of over a
>> socket. Why is this, plus setgid or something, a bad idea in any way?
>
> It is svnserve, just run in tunnel mode as the user who ssh'd in. I
> don't know what Brian is talking about. As for running it setgid,
> feel free to give it a shot, I don't know if anyone has tried that
> approach.
As Perry noticed, both use svnserve. Brian's point is that the two
methods that are causing confusion use it in different ways.
1) svn+ssh:// User tunnels to server and as himself runs svnserve *as
himself*. As mentioned many times, this is equivalent to file://
access.
2) Alternative method that uses the same components in a different way:
ssh tunnel with svn:// access via svnserve (which is configured to
allow localhost only connections). User tunnels to server and the
opens a network connection to svnserve which performs the action on the
user's behalf *with the permissions of the svnserve daemon.* This
alternative method achieves the setuid feature that Perry desires.
(2) requires two separate authentications. One sets up the ssh tunnel.
The other is the svnserve CRAM-MD5 authentication. Add non-ssh
encrypted data only travels through the localhost interface, so you
have not opened up any more outward-facing services.
I hope that provides some clarification.
-Travis
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: a few nits setting up svn...
Posted by Garrett Rooney <ro...@electricjellyfish.net>.
Perry E. Metzger wrote:
> Brian Mathis <bm...@directedge.com> writes:
>
>>The point is that there are already TWO other options that will allow
>>you to reach the goal you want. 1 is apache, and 2 is svnserve.
>>Using these requires ZERO code changes to svn. If apache doesn't meet
>>your needs, then fine, use svnserve over ssh.
>
>
> How about I drop using svn instead.
>
> Actually, I won't do that -- but please bear in mind that ignoring
> people's needs doesn't encourage people to use a program.
>
> So anyway, explain to me exactly how it is that svn+ssh works. What
> exactly is being invoked over the ssh connection? I was under the
> impression it WAS svnserve, just being run to stdout instead of over a
> socket. Why is this, plus setgid or something, a bad idea in any way?
It is svnserve, just run in tunnel mode as the user who ssh'd in. I
don't know what Brian is talking about. As for running it setgid, feel
free to give it a shot, I don't know if anyone has tried that approach.
-garrett
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: a few nits setting up svn...
Posted by "Perry E. Metzger" <pe...@piermont.com>.
Brian Mathis <bm...@directedge.com> writes:
> The point is that there are already TWO other options that will allow
> you to reach the goal you want. 1 is apache, and 2 is svnserve.
> Using these requires ZERO code changes to svn. If apache doesn't meet
> your needs, then fine, use svnserve over ssh.
How about I drop using svn instead.
Actually, I won't do that -- but please bear in mind that ignoring
people's needs doesn't encourage people to use a program.
So anyway, explain to me exactly how it is that svn+ssh works. What
exactly is being invoked over the ssh connection? I was under the
impression it WAS svnserve, just being run to stdout instead of over a
socket. Why is this, plus setgid or something, a bad idea in any way?
Perry
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: problems with sgid "svnserve"
Posted by "Perry E. Metzger" <pe...@piermont.com>.
"Perry E. Metzger" <pe...@piermont.com> writes:
> So it appears that, on linux (where I was running my tests), if the
> shell is executed and the effective gid != the real gid, the shell (or
> perhaps the kernel, I haven't looked at the source) sets the effective
> gid to the real gid first.
It is bash, being "helpful". I hadn't encountered this ever before
because I rarely use linux, and on most other systems /bin/sh is not
bash.
I've considered a number of solutions -- for now, the best of the bad
alternatives I seem to have is this c program, which I'm running as a
wrapper around "svnserve". I set it setuid root, setgid whatever group
I want the repository to be, and all is well, after a fashion.
I think something like this probably should be included with
subversion in the future, for the benefit of people who want to run
with a setgid svnserve and a repository set writable only to that
gid. Having svnserve itself be setuid root seems like a bad idea --
this program is small enough that it is probably safe.
----------------------------------------------------------------------
/*
* Wrapper to run the svnserve process setgid.
* The idea is to avoid the problem that some interpreters like bash
* invoked by svnserve in hook scripts will reset the effective gid to
* the real gid, nuking the effect of an ordinary setgid svnserve binary.
* Sadly, to set the real gid portably, you need to be root, if only
* for a moment.
* Also smashes the environment to something known, so that games
* can't be played to try to break the security of the hook scripts,
* by setting IFS, PATH, and similar means.
*/
/*
* Written by Perry Metzger, and placed into the public domain.
*/
#include <stdio.h>
#include <unistd.h>
#define REAL_PATH "/usr/bin/svnserve.real"
char *newenv[] = { "PATH=/bin:/usr/bin", "SHELL=/bin/sh", NULL };
int
main(int argc, char **argv)
{
if (setgid(getegid()) == -1) {
perror("setgid(getegid())");
return 1;
}
if (seteuid(getuid()) == -1) {
perror("seteuid(getuid())");
return 1;
}
execve(REAL_PATH, argv, newenv);
perror("attempting to exec " REAL_PATH " failed");
return 1;
}
----------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
problems with sgid "svnserve"
Posted by "Perry E. Metzger" <pe...@piermont.com>.
>> I created an svn group, made svnserve setgid "svn", and made the
>> repository db and locks directories and files writable by group
>> "svn". (It is nowhere documented what portions of the repository need
>> to be writable -- that's unfortunate.)
[...]
> Actually, this seems to be not entirely the case -- I'm having trouble
> with post-commit scripts. In particular, my commit mail script is not
> running sgid svn.
So it appears that, on linux (where I was running my tests), if the
shell is executed and the effective gid != the real gid, the shell (or
perhaps the kernel, I haven't looked at the source) sets the effective
gid to the real gid first. This does not appear to happen for other
interpreters. Perhaps someone who knows more about linux than me can
explain why -- I'm a poor BSDhead.
To get around this, I temporarily changed post-commit to a perl script
that sets the real gid to the effective gid and executes the real
script. Doubtless this provides for a bit of a security hole in that
one could play games the with the shell's file descriptors etc. --
doubtless the reason for the "protection" in the behavior -- but for
the moment, this has hacked around the issue for me.
Probably the right thing to do is to put some support into svnserve
for running the hooks in a sgid environment safely. Given that, the
rest of the stuff will just work right.
--
Perry E. Metzger perry@piermont.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: a few nits setting up svn...
Posted by "Perry E. Metzger" <pe...@piermont.com>.
"Perry E. Metzger" <pe...@piermont.com> writes:
> Having finally found out enough about how svnserve works from looking
> at the code and getting mail from people in private, it turned out to
> be pretty trivial.
>
> I created an svn group, made svnserve setgid "svn", and made the
> repository db and locks directories and files writable by group
> "svn". (It is nowhere documented what portions of the repository need
> to be writable -- that's unfortunate.)
>
> Anyway, all the existing code appears to more or less do the right
> thing already if I make svnserve setgid.
Actually, this seems to be not entirely the case -- I'm having trouble
with post-commit scripts. In particular, my commit mail script is not
running sgid svn.
Anyone have an idea why this might be? I can't see an obvious reason
this is happening, but I don't really understand how the scripts get
executed...
Perry
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: a few nits setting up svn...
Posted by "Perry E. Metzger" <pe...@piermont.com>.
Brian Mathis <bm...@directedge.com> writes:
> What we have here is an XYZ problem:
>
> Q: I want to use X to perform function Y, but instead it's doing Z.
> A: X doesn't perform function Y, use A instead
> Q: But I don't want to use A, I want to use X
> A: Too bad. X doesn't do what you want, but A does. Use A.
> Q: But I don't want to use A.
> ....
Having finally found out enough about how svnserve works from looking
at the code and getting mail from people in private, it turned out to
be pretty trivial.
I created an svn group, made svnserve setgid "svn", and made the
repository db and locks directories and files writable by group
"svn". (It is nowhere documented what portions of the repository need
to be writable -- that's unfortunate.)
Anyway, all the existing code appears to more or less do the right
thing already if I make svnserve setgid. I'd still prefer to make the
code a bit more conscious about whether it is running suid/sgid and
take precautions if need be, but for the moment the solution appears
to work. It might be nice to document it.
Perry
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: a few nits setting up svn...
Posted by Brian Mathis <bm...@directedge.com>.
Perry E. Metzger wrote:
>Brian Mathis <bm...@directedge.com> writes:
>
>
>>There's already a way to make all your accesses to the repos "suid" to
>>svn, it's called svnserve. Run it as user "svn" and viola, all
>>accesses through it are done as user "svn". Tunnel over ssh, and
>>you're done.
>>
>>
>
>Why bother? The direct tools can do exactly the same thing, and then I
>don't have to worry that svnserve is accidently misconfigured to
>listen to the wrong interface one morning. Fewer moving parts, fewer
>accidents.
>
>
Not enough moving parts, the machine doesn't work right.
The direct tools do NOT do excatly the same thing! If they did, 1 of
them wouldn't exist. If you are worried that your config files will
accidentally change, then you have bigger problems with security than
running a daemon.
What we have here is an XYZ problem:
Q: I want to use X to perform function Y, but instead it's doing Z.
A: X doesn't perform function Y, use A instead
Q: But I don't want to use A, I want to use X
A: Too bad. X doesn't do what you want, but A does. Use A.
Q: But I don't want to use A.
....
The point is that there are already TWO other options that will allow
you to reach the goal you want. 1 is apache, and 2 is svnserve. Using
these requires ZERO code changes to svn. If apache doesn't meet your
needs, then fine, use svnserve over ssh.
--
Brian Mathis
http://directedge.com/b/
Re: a few nits setting up svn...
Posted by "Perry E. Metzger" <pe...@piermont.com>.
Brian Mathis <bm...@directedge.com> writes:
>>As I said, the easiest thing of all is probably the 30 lines of code
>>needed to make the local access method successfully use suid. It
>>should probably just open the files it needs, record the real user ID,
>>and drop privs. Alternatively, given that we're talking suid "svn" and
>>not suid root, it may be sufficient just to record the real user ID so
>>that the right user is recorded in the logs etc...
>
> There's already a way to make all your accesses to the repos "suid" to
> svn, it's called svnserve. Run it as user "svn" and viola, all
> accesses through it are done as user "svn". Tunnel over ssh, and
> you're done.
Why bother? The direct tools can do exactly the same thing, and then I
don't have to worry that svnserve is accidently misconfigured to
listen to the wrong interface one morning. Fewer moving parts, fewer
accidents.
--
Perry E. Metzger perry@piermont.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: a few nits setting up svn...
Posted by Brian Mathis <bm...@directedge.com>.
Perry E. Metzger wrote:
[......]
>As I said, the easiest thing of all is probably the 30 lines of code
>needed to make the local access method successfully use suid. It
>should probably just open the files it needs, record the real user ID,
>and drop privs. Alternatively, given that we're talking suid "svn" and
>not suid root, it may be sufficient just to record the real user ID so
>that the right user is recorded in the logs etc...
>
>
There's already a way to make all your accesses to the repos "suid" to
svn, it's called svnserve. Run it as user "svn" and viola, all accesses
through it are done as user "svn". Tunnel over ssh, and you're done.
--
Brian Mathis
http://directedge.com/b/
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: a few nits setting up svn...
Posted by "Perry E. Metzger" <pe...@piermont.com>.
Ben Collins-Sussman <su...@collab.net> writes:
> Perry E. Metzger wrote:
>
>> Er, unfortunately, for good or ill, many people need to use
>> ssh. Sometimes this is simple good security sense -- you want to avoid
>> opening additional attack vectors for a machine.
>> Given that, what might I be able to do to tighten down the on-machine
>> security without adding another bunch of code to audit talking
>> off-machine?
>
> SSH isn't the only "safe" way to access a computer.
That's not the point. Good security policy says that every program is
buggy, and you thus want to rely on as few of them as possible. That's
sometimes called "aperture narrowing" by those of us who do security
work professionally (like me).
Most break ins are not caused by problems in protocols or failures to
encrypt -- they're caused by bugs in programs (like buffer overflows)
and problems with configurations.
Fewer services listening means fewer ways to break in and fewer
systems to audit.
> One solution is to use apache as your svn server, with SSL. Clients
> access via https://.
Some people prefer not to do this. Apache, for instance, is a very
large program compared to ssh, and is much harder to audit. Also, if
you already have ssh running on the box, you might not want to have to
add a second service if you can avoid it. See above.
Really, what I'm looking for is to make the access method to the
repository SUID to an "svn" account and get to it over ssh. That means
that the developers may have a potential way to break in to the svn
account if there are bugs in the access program, but I'm not that
concerned about that -- the main purpose is to keep them from
accidently damaging the repository rather than to provide "real"
security here. We mostly trust the developers and just want to stop
accidents.
However, we don't trust the wider world and would like to keep the
machine otherwise as tied down as possible -- which means ssh access
only.
> I'm just brainstorming here.
As I said, the easiest thing of all is probably the 30 lines of code
needed to make the local access method successfully use suid. It
should probably just open the files it needs, record the real user ID,
and drop privs. Alternatively, given that we're talking suid "svn" and
not suid root, it may be sufficient just to record the real user ID so
that the right user is recorded in the logs etc...
--
Perry E. Metzger perry@piermont.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: a few nits setting up svn...
Posted by Ben Collins-Sussman <su...@collab.net>.
Perry E. Metzger wrote:
> Er, unfortunately, for good or ill, many people need to use
> ssh. Sometimes this is simple good security sense -- you want to avoid
> opening additional attack vectors for a machine.
>
> Given that, what might I be able to do to tighten down the on-machine
> security without adding another bunch of code to audit talking
> off-machine?
SSH isn't the only "safe" way to access a computer.
One solution is to use apache as your svn server, with SSL. Clients
access via https://. You can even use client certificates if you're
extra paranoid. Either way, traffic is encrypted. And the accounts
aren't Unix accounts: they're in an apache user db. Apache+SSL has a
pretty darn good track record for security.
Another solution is to stick with svn:// and 'svnserve -d', but bind the
svnserve daemon only to localhost. If your users already have SSH
access, have them open an SSH tunnel to the server, and tunnel your
svn:// session over that. You get all the security of SSH, and avoid
the permissions headache of svn+ssh://.
I'm just brainstorming here.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: a few nits setting up svn...
Posted by "Perry E. Metzger" <pe...@piermont.com>.
Ben Collins-Sussman <su...@collab.net> writes:
>> Can I do that even if we're using the svn+ssh: access method? I thought
>> the daemon mode applied only if you were using the svn: method...
>
> That's correct. I'm suggesting that you *don't* use svn+ssh://,
> because it's no different than a bunch of users accessing the
> repository directly via file:///. Both file:/// and svn+ssh:// setups
> have the potential for huge permission headaches.
>
> I'm recommending that nothing ever access the repository but a single
> daemon server process: either apache (http://) or svnserve
> (svn://). Both servers have the ability to authenticate different
> users. SSH isn't required for that.
Er, unfortunately, for good or ill, many people need to use
ssh. Sometimes this is simple good security sense -- you want to avoid
opening additional attack vectors for a machine.
Given that, what might I be able to do to tighten down the on-machine
security without adding another bunch of code to audit talking
off-machine?
--
Perry E. Metzger perry@piermont.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: a few nits setting up svn...
Posted by Ben Collins-Sussman <su...@collab.net>.
Perry E. Metzger wrote:
> Can I do that even if we're using the svn+ssh: access method? I thought
> the daemon mode applied only if you were using the svn: method...
>
That's correct. I'm suggesting that you *don't* use svn+ssh://, because
it's no different than a bunch of users accessing the repository
directly via file:///. Both file:/// and svn+ssh:// setups have the
potential for huge permission headaches.
I'm recommending that nothing ever access the repository but a single
daemon server process: either apache (http://) or svnserve (svn://).
Both servers have the ability to authenticate different users. SSH
isn't required for that.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: a few nits setting up svn...
Posted by "Perry E. Metzger" <pe...@piermont.com>.
Ben Collins-Sussman <su...@collab.net> writes:
> On Thu, 2004-02-12 at 16:24, Perry E. Metzger wrote:
>
>> 4) As an aside, it would be neat if one could make the ra_svn goo
>> operate suid "svn" or something similar, so that the repository
>> could be writable only to "svn" and accidents could be avoided.
>
> Why don't you make the whole repository owned by user 'svn', then run
> 'svnserve' as a daemon, running as user 'svn'? That way, only one
> process will ever access the repository, and you don't need to worry
> about group perms or umasks or any other permissions accidents. Very
> clean and simple.
Can I do that even if we're using the svn+ssh: access method? I thought
the daemon mode applied only if you were using the svn: method...
--
Perry E. Metzger perry@piermont.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: a few nits setting up svn...
Posted by Dave Rolsky <au...@urth.org>.
On Fri, 13 Feb 2004, Perry E. Metzger wrote:
>
> Brian Mathis <bm...@directedge.com> writes:
> > I was thinking the same. IMO, directly accessing the files via file:
> > method and svn+ssh: is a really bad idea unless there's only 1 person
> > using it (ie, personal projects). The Unix permission scheme just
> > isn't cut out for robust multi-user sharing like what needs to be done
> > with svn.
>
> Unfortunately, svnserve is not an appropriate program for me to be
> advising people to put on an unprotected server. The svn+ssh method
> seems to be perfectly fine, provided that some small changes (and we
> are talking only 20 or 30 lines) are made so the tools can be run
> setuid "svn" or some such.
Couldn't you write a wrapper around svn for this purpose?
-dave
/*=======================
House Absolute Consulting
www.houseabsolute.com
=======================*/
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: a few nits setting up svn...
Posted by "Perry E. Metzger" <pe...@piermont.com>.
Brian Mathis <bm...@directedge.com> writes:
> I was thinking the same. IMO, directly accessing the files via file:
> method and svn+ssh: is a really bad idea unless there's only 1 person
> using it (ie, personal projects). The Unix permission scheme just
> isn't cut out for robust multi-user sharing like what needs to be done
> with svn.
Unfortunately, svnserve is not an appropriate program for me to be
advising people to put on an unprotected server. The svn+ssh method
seems to be perfectly fine, provided that some small changes (and we
are talking only 20 or 30 lines) are made so the tools can be run
setuid "svn" or some such.
> Go with apache/mod_svn or svnserve for large projects.
Apache is far too large to be audited and was never written with a
security architecture in mind. It is a fine web server -- but it is
not a fine secure access service.
If what you are doing is defending the machine running your candy
store's web site, there isn't any problem here. However, if, say, you
are defending the source code for something very valuable and there
are loads of highly motivated people who would love to make unseen
changes to it etc, you cannot be nearly so trusting.
I do security work for a living. Proper security hygiene says:
1) Run very few outward facing services on a machine that will be
attacked -- as few as you can. Each server process you run is a
potential weak spot, and the programmers are in each case fallible
and WILL have made mistakes. The more services you run, the higher
the likelyhood of one of them having a mistake that makes it
vulnerable to attack.
2) Carefully defend each of the services you have to run to the best
of your ability.
On my personal boxes, for example, I run named and ntpd, but in each
case the process is run unprivileged, chrooted and tied up with Niels
Provos' wonderful systrace system that restricts the system calls each
can run. I also run sshd, but I run it priv separated and with
systrace to the extent that I can.
Is this perfect security? No, but it is a damn sight better than what
most people out there do, and it would be a much higher barrier to
attack. I'm sure things will be broken into some time, but it won't
happen nearly as often as it will for other people who aren't
careful.
Is it paranoid or dumb to run things this way? No. We live in a world
where the tools for doing break-ins are now automated, and where a new
Linux box put on the net can expect its first break-in attempt within
five minutes. No, that's not a joke. That's just the truth -- run an
IDS system some time and see. Assuming you should be careful in how
you set things up is the only sane way to run things. Its like
wearing seat belts -- you're still at risk, but the odds are much
better for you.
Is it inconvenient running things this way? Not in the least. It takes
a little more time setting up your named to run chrooted and unprived,
but once it is set up you never notice the difference again -- and you
don't have trouble sleeping at night.
So lets get back to Subversion. You ask me, merely to run a version
control system for a few users, to add on things like apache and/or
svnserver. I have no need to do that -- there is already ssh for
remote access, and svn works with that quite well from what I can tell
modulo a couple of nits. Even if I believed the developers of apache
and svnserver were saints, I am increasing my vulnerability -- and for
no obvious gain. As it happens, I don't believe in the perfection of
the programming work done by the Apache people or anyone else.
So, call me a kook if you like, but there are many projects I
participate in, like NetBSD, that agree with me about the importance
of security and making sure that you minimize the threats to the
extent that you can if you're doing important work.
As for what changes are needed here, as I said, simply allowing the
tools for svn+ssh access to run suid "svn" or "src" or some such would
likely fix the only problem I have with it right now. Yes, holes in
those tools might give the users unlimited access to the "svn"
account's privs and thus the repository, but as it happens the
universe of users is fairly small and well trusted, and in any case
can do pretty heavy damage just by committing buggy code.
So given the minimal changes I need to get *exactly* what I want, and
the non-existent gain in using the other access methods, I don't see
why I would want to use apache or svnserver.
--
Perry E. Metzger perry@piermont.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: a few nits setting up svn...
Posted by Brian Mathis <bm...@directedge.com>.
Ben Collins-Sussman wrote:
>On Thu, 2004-02-12 at 16:24, Perry E. Metzger wrote:
>
>
>>4) As an aside, it would be neat if one could make the ra_svn goo
>> operate suid "svn" or something similar, so that the repository
>> could be writable only to "svn" and accidents could be avoided.
>>
>>
>Why don't you make the whole repository owned by user 'svn', then run
>'svnserve' as a daemon, running as user 'svn'? That way, only one
>process will ever access the repository, and you don't need to worry
>about group perms or umasks or any other permissions accidents. Very
>clean and simple.
>
>
I was thinking the same. IMO, directly accessing the files via file:
method and svn+ssh: is a really bad idea unless there's only 1 person
using it (ie, personal projects). The Unix permission scheme just isn't
cut out for robust multi-user sharing like what needs to be done with svn.
Go with apache/mod_svn or svnserve for large projects.
--
Brian Mathis
http://directedge.com/b/
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: a few nits setting up svn...
Posted by Ben Collins-Sussman <su...@collab.net>.
On Thu, 2004-02-12 at 16:24, Perry E. Metzger wrote:
> 4) As an aside, it would be neat if one could make the ra_svn goo
> operate suid "svn" or something similar, so that the repository
> could be writable only to "svn" and accidents could be avoided.
Why don't you make the whole repository owned by user 'svn', then run
'svnserve' as a daemon, running as user 'svn'? That way, only one
process will ever access the repository, and you don't need to worry
about group perms or umasks or any other permissions accidents. Very
clean and simple.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org