File: 4.html

package info (click to toggle)
lg-issue91 1-2
links: PTS
area: main
in suites: sarge
size: 3,084 kB
ctags: 266
sloc: ansic: 1,343; perl: 104; sh: 98; makefile: 34
file content (558 lines) | stat: -rw-r--r-- 17,817 bytes
<!--startcut  ==============================================-->
<!-- *** BEGIN HTML header *** -->
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML><HEAD>
<META NAME="generator" CONTENT="lgazmail v1.4G.h">
<TITLE>The Answer Gang 91: Secure CVS - SSH tunnel problem</TITLE>
</HEAD><BODY BGCOLOR="#FFFFFF" TEXT="#000000" LINK="#0000FF" VLINK="#0000AF"
ALINK="#FF0000">
<!-- *** END HTML header *** -->
<!--endcut  ==============================================-->
<!-- begin 4 -->
<H3 align="left"><img src="../../gx/dennis/qbubble.gif" 
	height="50" width="60" alt="(?) " border="0"
	>Secure CVS - SSH tunnel problem</H3>


<p><strong>From jonathan soong 
</strong></p> 
<p></strong></p>

<p align="right"><strong>Answered By  Thomas Adam, Ben Okopnik, Jason Creighton, Kapil Hari Paranjape
</strong></p>
<P><STRONG>
Hi Gang,
</STRONG></P>
<P><STRONG>
I have been trying to install CVS securely on a machine that will be
live on the Internet.
</STRONG></P>
<P><STRONG>
There are two ways i was hoping to secure it:
</STRONG></P>

<p><Strong><ol>
<LI>chroot jail - this has been done (there are plenty of HOW-TO's on the



<LI>secure pserver (pserver is used to remotely login to CVS).

</ol></Strong></p>
<P><STRONG>
My problem is with (2) - securing pserver:
</STRONG></P>
<P><STRONG><BLOCKQuote>
A common way of addressing this is to replace rsh with ssh, however
AFAIK this requires shell accounts
on the machine, a situation i <em> _have</em> to avoid.
</BLOCKQuote></STRONG></P>
<blockQuote>
<IMG SRC="../../gx/dennis/bbub.gif" ALT="(!)"
	HEIGHT="28" WIDTH="50" BORDER="0"
	> [Thomas] 
Why? Creating a "dummy" account is easy enough.
</blockQuote>
<P><STRONG>
<IMG SRC="../../gx/dennis/qbub.gif" ALT="(?)"
	HEIGHT="28" WIDTH="50" BORDER="0"
	> 
The solution i have which seems feasible is:
</STRONG></P>
<P><STRONG><BLOCKQuote>
Using pserver's user management, tunnelled over ssh with a generic
ssh login and some sort of restricted shell.
</BLOCKQuote></STRONG></P>
<P><STRONG>
I'm currently investigation this solution, however i'm not sure if there
is a fundamental security flaw in
this model, or what the restricted shell should look like.
</STRONG></P>
<P><STRONG>
I was wondering if you had any thoughts/opinions/suggestions on this? Or
perhaps be able to point out a
*much** easier way to secure it, that i missed!!
</STRONG></P>
<P><STRONG>
Any help would be much appreciated,
</STRONG></P>
<P><STRONG>
Jon
</STRONG></P>
<blockQuote>
<IMG SRC="../../gx/dennis/bbub.gif" ALT="(!)"
	HEIGHT="28" WIDTH="50" BORDER="0"
	> [Thomas] 
If CVS is the only thing that the "users" will be using, then it is
conceivable that you can have a "generic" login via SSH whereby this
"user" has CVS as its default $SHELL.
</blockQuote>
<blockQuote>
While I am not particularly sure of the security implications that my
following suggestion has, I think that you could do something like this:
</blockQuote>

<blockQuote><ol>
<LI>Create a generic account


<LI>edit "/etc/shells" and add at the bottom "/usr/bin/cvs"


<LI>Save the file.


<LI>change the generic user's shell.

</ol></blockQuote>
<blockQuote>
(at this point, I am wondering whether or not it is a good idea to create
a "wrapper" account for this "new" shell, something like:
</blockQuote>
<p align="center">See attached <tt><a href="../misc/tag/shellwrap.thomas.bash.txt">shellwrap.thomas.bash.txt</a></tt></p>
<blockQuote>
And saving it as "<TT>/sbin/cvsshell</TT>", which you could then add to
"<TT>/etc/shells</TT>" instead?
</blockQuote>
<blockQuote>
<IMG SRC="../../gx/dennis/bbub.gif" ALT="(!)"
	HEIGHT="28" WIDTH="50" BORDER="0"
	> [Ben] 
What happens when somebody suspends or "kill -9"s the shell? What new
attack scenarios can you expect from this? What would happen if a local
user launched this shell after hosing an environment variable (<TT>/a</TT> la/
the emacs/IFS attack scenario from the old days)?
</blockQuote>
<blockQuote>
<IMG SRC="../../gx/dennis/bbub.gif" ALT="(!)"
	HEIGHT="28" WIDTH="50" BORDER="0"
	> [Thomas] 
Errrm, I guess my answer to this is a bleak one...
</blockQuote>
<blockQuote>
<IMG SRC="../../gx/dennis/bbub.gif" ALT="(!)"
	HEIGHT="28" WIDTH="50" BORDER="0"
	> [Ben] 
It's probably best to just launch <em> _shells</em> that way and let those guys
answer this kind of questions. 
<IMG SRC="../../gx/dennis/smily.gif" ALT=":)" 
		height="24" width="20" align="middle">
</blockQuote>
<blockQuote>
<IMG SRC="../../gx/dennis/bbub.gif" ALT="(!)"
	HEIGHT="28" WIDTH="50" BORDER="0"
	> [Thomas] 
Aye...
</blockQuote>
<blockQuote>
(Details of step 4.) That way when the user is created,
</blockQuote>

<blockQuote><ul>
<!-- *) Edit "/etc/passwd" -->

<LI>Edit "/etc/passwd"

<!-- *) find the newly created user -->

<LI>find the newly created user

<!-- *) edit "/bin/bash" to "/sbin/cvsshell" (without quote signs mind you) -->

<LI>edit "/bin/bash" to "/sbin/cvsshell" (without quote signs mind you)

<!-- *) and save the file. -->

<LI>and save the file.
</ul></blockQuote>
<blockQuote>
Then you can use "ssh" to login into the newly created user and the
default shell would be CVS by default.
</blockQuote>
<blockQuote>
I'm not sure how secure this would be.......
</blockQuote>
<blockQuote>
Using "rbash" is not an option in this case.
</blockQuote>

<blockquote><em><font color="#000066">In almost-as-we-hit-the-press news, it looks like pserver doesn't
require the local user to have a <EM>useful</EM> shell, so /bin/false should
work. According to the querent, anyway.  I'm not preceisely sure of the
configuration on the pserver side that leads to that, though.
 -- Heather</font></em></blockquote>
<blockQuote>
<IMG SRC="../../gx/dennis/bbub.gif" ALT="(!)"
	HEIGHT="28" WIDTH="50" BORDER="0"
	> [Thomas] 
Before using this, I am sure other people will flame me for it (hey Ben)

<IMG SRC="../../gx/dennis/smily.gif" ALT=":)" 
		height="24" width="20" align="middle"> but.......it is a learning curve for me too 
<IMG SRC="../../gx/dennis/smily.gif" ALT=":)" 
		height="24" width="20" align="middle">
</blockQuote>
<blockQuote>
<IMG SRC="../../gx/dennis/bbub.gif" ALT="(!)"
	HEIGHT="28" WIDTH="50" BORDER="0"
	> [Ben] 
Don't look at me, buddy. It's been at least, what, an hour since I've
flamed you? I'm still in my refractory period.
</blockQuote>
<blockQuote>
<IMG SRC="../../gx/dennis/bbub.gif" ALT="(!)"
	HEIGHT="28" WIDTH="50" BORDER="0"
	> [Thomas] 
LOL, an hour? Is that all?? Things are looking up for me then 
<IMG SRC="../../gx/dennis/smily.gif" ALT=":)" 
		height="24" width="20" align="middle">
</blockQuote>
<blockQuote>
Hmmm, it was just an idea..... I'm curious as to whether it <EM>would</EM> work,
minus some of the security implications......
</blockQuote>
<blockQuote>
<IMG SRC="../../gx/dennis/bbub.gif" ALT="(!)"
	HEIGHT="28" WIDTH="50" BORDER="0"
	> [Ben] 
To querent: I've never used CVS over SSH, etc., but you might want to
take a look at "scponly" &lt;<A HREF="http://www.sublimation.org/scponly/&gt"
	>http://www.sublimation.org/scponly/&gt</A>;. It's
designed for the kind of access you're talking about (if I understood
you correctly), and is very flexible WRT user management (one anonymous
user is fine, so are multi-user setups.)
</blockQuote>
<P><STRONG>
<IMG SRC="../../gx/dennis/qbub.gif" ALT="(?)"
	HEIGHT="28" WIDTH="50" BORDER="0"
	> 
Hi guys,
</STRONG></P>
<P><STRONG>
Thanks for your help, i decided to implement it like so:
</STRONG></P>
<P><STRONG><BLOCKQuote>
SECURE CVS without multiple unix accounts
</BLOCKQuote></STRONG></P>

<p><Strong><ol>
<LI>make user 'cvsd'  who has r/w access to the CVS repository


<LI>set 'cvsd's shell to /bin/bash (or some proper shell) in /etc/passwd


<LI>set 'cvsd's password to * in /etc/shadow


<LI>have all developers who are using the CVS generate an ssh key



<LI>put an entry in 'cvsd's /home/cvsd/.ssh/authorized_keys2 file that looks like:



</ol></Strong></p>
<P><STRONG>
Now only those developers who have sent you keys will be able to login
(passwordless) to the CVS machine and will be automatically be dumped to
sleep for 3 hours - this will keep the ssh port forward open.
</STRONG></P>
<blockQuote>
<IMG SRC="../../gx/dennis/bbub.gif" ALT="(!)"
	HEIGHT="28" WIDTH="50" BORDER="0"
	> [Thomas] 
Sounds like a good idea this way.
</blockQuote>
<P><STRONG>
<IMG SRC="../../gx/dennis/qbub.gif" ALT="(?)"
	HEIGHT="28" WIDTH="50" BORDER="0"
	> 
Now i can securely use CVS's pserver user management, without multiple
unix users.
</STRONG></P>
<P><STRONG>
Anyone have any thoughts on the security implications of forcing the
users to execute 'sleep 3h'
e.g. can this be broken by sending weird signals?
</STRONG></P>
<blockQuote>
<IMG SRC="../../gx/dennis/bbub.gif" ALT="(!)"
	HEIGHT="28" WIDTH="50" BORDER="0"
	> [Thomas] 
Assuming that the command "sleep 3h" is spawned once the user logs in,
then as with any process this can be killed by doing:
</blockQuote>

<blockquote><pre>kill -9 $(pidof "sleep 3h")
</pre></blockquote>
<blockQuote>
(I have seen the command "pidof" on <A HREF="http://www.debian.org/">Debian</A>, <A HREF="http://www.suse.com/">SuSE</A> and RH -- it might <EM>not</EM>
be distributed with <A HREF="http://www.slackware.org/">Slackware</A> as this claims to be more POSIX compliant,
something that "pidof" is not).
</blockQuote>
<blockQuote>
<IMG SRC="../../gx/dennis/bbub.gif" ALT="(!)"
	HEIGHT="28" WIDTH="50" BORDER="0"
	> [Jason] 
Sure enough, slackware 8.1 has this command: (And, just for the record,
Slackware is more BSD-ish. I've never heard a claim that it is more POSIX
compliant.)
</blockQuote>

<blockquote><pre>~$ about pidof
/sbin/pidof:    symbolic link to killall5
/sbin/killall5: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV),
dynamically linked (uses shared libs), stripped
~$ greppack killall5
sysvinit-2.84-i386-19
</pre></blockquote>
<blockQuote>
(Of course, to use the 'about' and 'greppack' scripts, you'd have to ask me to
post them.)
</blockQuote>

<blockquote><em><font color="#000066">Last I recall POSIX was a stnadard that declared minimum shell and
syscall functionality, so I don't see why it would insist on having you
leave a feature out.  In fact "minimum" is the key since merely
implementing POSIX alone doesn't get a usable runtime environment, as
proved by Microsoft.
 -- Heather</font></em></blockquote>
<blockQuote>
<IMG SRC="../../gx/dennis/bbub.gif" ALT="(!)"
	HEIGHT="28" WIDTH="50" BORDER="0"
	> [Thomas] 
The more traditional method, is to use something like....
</blockQuote>

<blockquote><pre>kill -9 $(ps aux | grep "sleep\ 3h" | grep -v "sleep\ 3h" | awk '{print
$2}'
</pre></blockquote>
<blockQuote>
If this happens then the rest of your command will fail.
</blockQuote>
<blockQuote>
The security implications of this, is that the rest of the command will
never get executed. I came up with a "bash daemon" script three years ago
that would re-spawn itself by "exec loop4mail $!" which used the same
process number as the initial "loop4mail &amp;" command.
</blockQuote>
<blockQuote>
Security was not paramount in <EM>that</EM> case.
</blockQuote>
<blockQuote>
If the command is killed, then the users will most likely be left dangling
at the Bash prompt.....
</blockQuote>
<blockQuote>
<IMG SRC="../../gx/dennis/bbub.gif" ALT="(!)"
	HEIGHT="28" WIDTH="50" BORDER="0"
	> [Ben] 
Well, the "about" script is rather obvious,
</blockQuote>
<blockQuote>
<IMG SRC="../../gx/dennis/bbub.gif" ALT="(!)"
	HEIGHT="28" WIDTH="50" BORDER="0"
	> [Jason] 
Basically, the only thing it does is follow symlinks recursivly, and calls
"file" with a full list.
</blockQuote>
<blockQuote>
<IMG SRC="../../gx/dennis/bbub.gif" ALT="(!)"
	HEIGHT="28" WIDTH="50" BORDER="0"
	> [Thomas] 
Hmmm, I have a similar script to yours that you describe here, Jason,
except that mine "traverses" the symlinks <EM>until</EM> file returns anything !=
to another symlink. If it does, then it keeps traversing.
</blockQuote>
<blockQuote>
<IMG SRC="../../gx/dennis/bbub.gif" ALT="(!)"
	HEIGHT="28" WIDTH="50" BORDER="0"
	> [Jason] 
Okay, I think I see what you're saying now: A symlink will <EM>never</EM> point to
more than one thing. Therefore, we could solve the problem with a loop,
breaking out of it when there are no more symlinks to process. Recursion is
not required.
</blockQuote>
<blockQuote>
Hmm... that's interesting. However, I already wrote the recursive version
already, so I'll stick with that. 
<IMG SRC="../../gx/dennis/smily.gif" ALT=":-)" 
		height="24" width="20" align="middle">
</blockQuote>
<blockQuote>
If a symlink doesn't point to anything, it will fail a test for file
existance:
</blockQuote>

<blockquote><pre>~/tmp$ ln -s doesnotexist symlink
~/tmp$ ls -l
total 0
lrwxrwxrwx    1 jason    users          12 May 27 10:46 symlink -&gt;
doesnotexist
~/tmp$ [ -e symlink ] &amp;&amp; echo "symlink exists"
~/tmp$
</pre></blockquote>
<blockQuote>
Circular symlinks are fun too.......
</blockQuote>
<blockQuote>
<IMG SRC="../../gx/dennis/bbub.gif" ALT="(!)"
	HEIGHT="28" WIDTH="50" BORDER="0"
	> [Thomas] 
My logic in this is simple in that a symlink <EM>must</EM> point to a physical
store of data, albeit a directory, file, block file, etc. Also, you might
want to look at the program "chase" which is rather useful in these
situations too.
</blockQuote>
<blockQuote>
<IMG SRC="../../gx/dennis/bbub.gif" ALT="(!)"
	HEIGHT="28" WIDTH="50" BORDER="0"
	> [Jason] 
Haven't heard of that one and it's not on my system.
</blockQuote>
<blockQuote>
<IMG SRC="../../gx/dennis/bbub.gif" ALT="(!)"
	HEIGHT="28" WIDTH="50" BORDER="0"
	> [Kapil] 
Two programs that are useful to traverse symlinks come with standard
distributions: namei (util-linux) and readlink (coreutils/fileutils)
</blockQuote>

<blockquote><pre>	$ namei /usr/bin/vi
</pre></blockquote>
<blockQuote>
Gives
</blockQuote>

<blockquote><pre>	f: /usr/bin/vi
	 d /
	 d usr
	 d bin
	 l vi -&gt; /etc/alternatives/vi
	   d /
	   d etc
	   d alternatives
	   l vi -&gt; /usr/bin/nvi
	     d /
	     d usr
	     d bin
	     - nvi
</pre></blockquote>
<blockQuote>
While
</blockQuote>

<blockquote><pre>	$ readlink -f /usr/bin/vi
</pre></blockquote>
<blockQuote>
Gives
</blockQuote>

<blockquote><pre>	/usr/bin/nvi
</pre></blockquote>
<blockQuote>
<IMG SRC="../../gx/dennis/bbub.gif" ALT="(!)"
	HEIGHT="28" WIDTH="50" BORDER="0"
	> [Thomas] 
This feature might be superfluous to your initial script, but I find it
quite useful. "find" is a very powerful utility.
</blockQuote>
<blockQuote>
So I shall extend you the same offer, and say that I'll post you my
script, if you like.... 
<IMG SRC="../../gx/dennis/smily.gif" ALT=":)" 
		height="24" width="20" align="middle">
</blockQuote>
<blockQuote>
<IMG SRC="../../gx/dennis/bbub.gif" ALT="(!)"
	HEIGHT="28" WIDTH="50" BORDER="0"
	> [Ben] 
...but "greppack" has to do
with Slackware's package management...
</blockQuote>
<blockQuote>
<IMG SRC="../../gx/dennis/bbub.gif" ALT="(!)"
	HEIGHT="28" WIDTH="50" BORDER="0"
	> [Jason] 
Bingo. All it does is print the name of a file if a regex matches somewhere in
it, because Slackware's package "management" is quite simple.
</blockQuote>
<blockQuote>
[time passes]
</blockQuote>
<blockQuote>
I was just looking at the options for 'grep' and it turns out that I could
just call grep, like so:
</blockQuote>

<blockquote><pre>grep killall5 -l /var/log/packages/*
</pre></blockquote>
<blockQuote>
'-l' causes grep to print the names of the files that match, not the lines
that match.
</blockQuote>

<blockquote><code><font color="#000033"><br>Jason Creighton, CEO of Wheel Reinvention Corp.
<br>(Our motto: "Code reuse is silly")
</font></code></blockquote>
<blockQuote>
<IMG SRC="../../gx/dennis/bbub.gif" ALT="(!)"
	HEIGHT="28" WIDTH="50" BORDER="0"
	> [Ben] 
... and so would not be anything like
Debian - where you'd just do "dpkg -S killall5" to find out the package
it came from. I'll say this: in almost everything I've ever thought to
ask of a packaging system, between "dpkg", "apt-get", and "apt-cache",
Debian has a good, well-thought-out answer. The one thing that's not
handled - and I don't really see how it could be without adding about
5MB that most folks would never use - is looking up a file that's in the
Debian distro but is <EM>not</EM> installed on my system. I handle that by
downloading the "Contents-i386.gz" file once every few months and
"zgrep"ping through it; it's saved my bacon many, many times when a
compile went wrong.
</blockQuote>
<blockQuote>
<IMG SRC="../../gx/dennis/bbub.gif" ALT="(!)"
	HEIGHT="28" WIDTH="50" BORDER="0"
	> [Kapil] 
To make this lookup faster you may want to install "dlocate" which is to
"dpkg" (info part) what "locate" is to "find".
</blockQuote>
<blockQuote>
<IMG SRC="../../gx/dennis/bbub.gif" ALT="(!)"
	HEIGHT="28" WIDTH="50" BORDER="0"
	> [Ben] 
Cool - thank you! That was my one minor gripe about "dpkg" - on my
system, it takes about 20 seconds (which is <EM>years</EM> in computer time 
<IMG SRC="../../gx/dennis/smily.gif" ALT=":)" 
		height="24" width="20" align="middle">
to look things up.
</blockQuote>
<blockQuote>
<IMG SRC="../../gx/dennis/bbub.gif" ALT="(!)"
	HEIGHT="28" WIDTH="50" BORDER="0"
	> [Kapil] 
And for those with network connectivity:
</blockQuote>
<blockQuote><BLOCKQuote>
<A HREF="http://packages.debian.org"
	>http://packages.debian.org</A>
</BLOCKQuote></blockQuote>
<blockQuote>
Contains a search link as well.
</blockQuote>
<blockQuote>
<IMG SRC="../../gx/dennis/bbub.gif" ALT="(!)"
	HEIGHT="28" WIDTH="50" BORDER="0"
	> [Ben] 
Unfortunately, that does not describe me very well. 
<IMG SRC="../../gx/dennis/unsmily.gif" ALT=":(" 
		height="24" width="20" align="middle"> Otherwise, I'd
just have written a little Perl interface to the search page and been
done with it. Instead, I download a 5MB or so file when I have good
connectivity so I have it to use for the rest of the time.
</blockQuote>

<!-- end 4 -->