Re: Setuid
On 7/22/2011 8:38 AM, Andy Canfield wrote: Had what seems to be a bright idea. It is a bright idea for a Subversion server on Linux or OS X; AFAIK this idea has no relevance to Windows: Take note of the user and group that Apache runs as. Call this combination APACHE, meaning APACHE_USER and APACHE_GROUP. Whatever mod_dav_svn does to any repository will be done by APACHE. Whatever WebSVN does to any repository will be done by APACHE. If I set the svnserve program to be owned by APACHE, and setuid and setgid, then whatever svnserve does to any repository will also be done by APACHE. Only root, or the APACHE user, can make this change to the svnserve program binary. If I set the svnadmin program to be owned by APACHE, and setuid and setgid, then whatever svnadmin does to any repository will also be done by APACHE. If I set the svnlook program to be owned by APACHE, and setuid and setgid, then whatever svnlook does to any repository will be done by APACHE. So the three access paths - http:, svn:, and direct - will all operate using the same user and group. You don't want to do this to any program, such as 'svn', which relies on user authentication, since it needs to know the actual user that is running the program. But any program which operates directly on the repository can be set this way and that ensures that the repository is always manipulated, at a low level, by the same user all the time. So a post-installation setup would include: *sudo bash cd /usr/bin chown APACHE_USER svnadmin svnlook svnserve chgrp APACHE_GROUP svnadmin svnlook svnserve* This idea also allows me to make the the respository itself accessable only by APACHE. This ensures that the repository can only be manipulated by Subversion code itself (or by root): *sudo bash mkdir /var/svn chown APACHE_USER**/var/svn* *chgrp APACHE_GROUP**/var/svn* *chmod 0700 /var/svn* If I also do this: *sudo bash rm /usr/bin/svnadmin* then all repository creation would have to be done via something like WebSVN, which I assume requires authentication. How does that sound to you guys? Where are the flaws in this idea? Thank you very much. It prevents privately owned and managed repositories. Normally, individual users can set up their own repositories for their own (personal) projects or files. If you are planning to do this on a server that you wish to lock down, then I see no reason why it would cause problems, but if users can login and do other work on this machine, you are constraining them. -- David Chapman dcchap...@acm.org Chapman Consulting -- San Jose, CA
Re: Setuid
On 7/22/2011 10:38 AM, Andy Canfield wrote: If I set the svnserve program to be owned by APACHE, and setuid and setgid, then whatever svnserve does to any repository will also be done by APACHE. Only root, or the APACHE user, can make this change to the svnserve program binary. You don't need suid for this. There are normally shell scripts that start system services that are executed as root and can change their uid before starting the program. Apache is an exception because it typically has to open port 80 for listening and ports below 1024 are restricted to root in unix-like systems - so it has to start as root and change its own uid after opening the socket. If I set the svnadmin program to be owned by APACHE, and setuid and setgid, then whatever svnadmin does to any repository will also be done by APACHE. I wouldn't do that without auditing the code. If there are any paths of execution that can delete or modify files, making it suid gives any local user the ability to delete/modify your repositories and anything else owned by apache. Normally, the point of running a network service with authentication is to prevent most users from having direct access to the files under control. Plus, users may want to have their own private subversion repositories that they create with svnadmin and use file:// access in svn. -- Les Mikesell lesmikes...@gmail.com
Re: Setuid
On Fri, Jul 22, 2011 at 11:38 AM, Andy Canfield wrote: > Had what seems to be a bright idea. It is a bright idea for a Subversion > server on Linux or OS X; AFAIK this idea has no relevance to Windows: > > Take note of the user and group that Apache runs as. Call this combination > APACHE, meaning APACHE_USER and APACHE_GROUP. > > Whatever mod_dav_svn does to any repository will be done by APACHE. Whatever > WebSVN does to any repository will be done by APACHE. > > If I set the svnserve program to be owned by APACHE, and setuid and setgid, > then whatever svnserve does to any repository will also be done by APACHE. > Only root, or the APACHE user, can make this change to the svnserve program > binary. Sounds dangerous and untested. svnserve, for example, is not designed to be run suid. It's not necessarily handling UID versus EUID correctly for this. (It might, it's not tested.) It's much more common to turn it around. If you want a shared svn://, svn+ssh://, and http:// access to the same repository, run a secondary Apache daemon as the alternative "svn" user. I've done so to keep Apache access separate from svn access quite successfully. Run it on another port to avoid conflicts with the primary Apache server, store logs in a distinct location in the config files, use a proxy on the main server to pass requests for https://sitename/svn/ to the https://sitename:8443/svn/, or a similar ProxyPass setup, and it helps you run multiple services safely on the same server. > If I set the svnadmin program to be owned by APACHE, and setuid and setgid, > then whatever svnadmin does to any repository will also be done by APACHE. > > If I set the svnlook program to be owned by APACHE, and setuid and setgid, > then whatever svnlook does to any repository will be done by APACHE. > > So the three access paths - http:, svn:, and direct - will all operate using > the same user and group. > > You don't want to do this to any program, such as 'svn', which relies on > user authentication, since it needs to know the actual user that is running > the program. But any program which operates directly on the repository can > be set this way and that ensures that the repository is always manipulated, > at a low level, by the same user all the time. > > So a post-installation setup would include: > sudo bash > cd /usr/bin > chown APACHE_USER svnadmin svnlook svnserve > chgrp APACHE_GROUP svnadmin svnlook svnserve > > This idea also allows me to make the the respository itself accessable only > by APACHE. This ensures that the repository can only be manipulated by > Subversion code itself (or by root): > sudo bash > mkdir /var/svn > chown APACHE_USER /var/svn > chgrp APACHE_GROUP /var/svn > chmod 0700 /var/svn > > If I also do this: > sudo bash > rm /usr/bin/svnadmin > then all repository creation would have to be done via something like > WebSVN, which I assume requires authentication. > > How does that sound to you guys? Where are the flaws in this idea? > > Thank you very much. > >
Re: Setuid
On 07/22/2011 11:29 PM, David Chapman wrote: On 7/22/2011 8:38 AM, Andy Canfield wrote: Had what seems to be a bright idea. It is a bright idea for a Subversion server on Linux or OS X; AFAIK this idea has no relevance to Windows: Take note of the user and group that Apache runs as. Call this combination APACHE, meaning APACHE_USER and APACHE_GROUP. Whatever mod_dav_svn does to any repository will be done by APACHE. Whatever WebSVN does to any repository will be done by APACHE. If I set the svnserve program to be owned by APACHE, and setuid and setgid, then whatever svnserve does to any repository will also be done by APACHE. Only root, or the APACHE user, can make this change to the svnserve program binary. If I set the svnadmin program to be owned by APACHE, and setuid and setgid, then whatever svnadmin does to any repository will also be done by APACHE. If I set the svnlook program to be owned by APACHE, and setuid and setgid, then whatever svnlook does to any repository will be done by APACHE. So the three access paths - http:, svn:, and direct - will all operate using the same user and group. You don't want to do this to any program, such as 'svn', which relies on user authentication, since it needs to know the actual user that is running the program. But any program which operates directly on the repository can be set this way and that ensures that the repository is always manipulated, at a low level, by the same user all the time. So a post-installation setup would include: *sudo bash cd /usr/bin chown APACHE_USER svnadmin svnlook svnserve chgrp APACHE_GROUP svnadmin svnlook svnserve* This idea also allows me to make the the respository itself accessable only by APACHE. This ensures that the repository can only be manipulated by Subversion code itself (or by root): *sudo bash mkdir /var/svn chown APACHE_USER**/var/svn* *chgrp APACHE_GROUP**/var/svn* *chmod 0700 /var/svn* If I also do this: *sudo bash rm /usr/bin/svnadmin* then all repository creation would have to be done via something like WebSVN, which I assume requires authentication. How does that sound to you guys? Where are the flaws in this idea? Thank you very much. It prevents privately owned and managed repositories. Normally, individual users can set up their own repositories for their own (personal) projects or files. If you are planning to do this on a server that you wish to lock down, then I see no reason why it would cause problems, but if users can login and do other work on this machine, you are constraining them. Ah, I see a lack of terminology here. Consider the respository located at /var/svn/sample, the repository named "sample" and accessed through the browser as "http://example.com/svn/sample";. What is the name for "/var/svn"? Is it a "Repository Collection"? The config entry is "SVNParentPath", so let's call it the "SVNParent". If you have an account on that server computer, and you don't have root access, and you want your own pesonal repository collection, then even today you can't use http: access to it, either because you can't configure Apache or because Apache is already configured for the standard SVNParent. The suggestion would make the SVNParent accessable only through the standard software, never directly. Any user could create his own respository, but it would be in the standard SVNParent. If /usr/bin/svnserve is owned by www-data (APACHE) and setuid, then you can't run /usr/bin/svnserve to access your own personal SVNParent. It can access your own repository in the standard SVNParent, but not your own SVNParent. However, it appears that it can be done using two Linux commands: *copy /usr/bin/svnserve ~/bin/svnserve copy /usr/bin/svnadmin ~/bin/svnadmin* The copies are owned by you and are no longer setuid. So you can run ~/bin/svnserve and it will operate under your user name and manage your own personal SVNParent. (I have not tested this yet, but it "should work"). On Fri, 22 Jul 2011 13:24:55 -0400 Nico Kadel-Garcia wrote: Sounds dangerous and untested. svnserve, for example, is not designed to be run suid. It's not necessarily handling UID versus EUID correctly for this. (It might, it's not tested.) That sounds like a serious concern; no way to be sure. But for me it would be worth the experiment.
