rssh-discuss Mailing List for rssh (Page 29)
Brought to you by:
xystrus
You can subscribe to this list here.
2003 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(4) |
Jun
(1) |
Jul
(15) |
Aug
(33) |
Sep
(5) |
Oct
(15) |
Nov
(8) |
Dec
(4) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2004 |
Jan
(5) |
Feb
|
Mar
(5) |
Apr
(4) |
May
(4) |
Jun
(15) |
Jul
(9) |
Aug
(11) |
Sep
(5) |
Oct
(2) |
Nov
|
Dec
(6) |
2005 |
Jan
(8) |
Feb
(6) |
Mar
(43) |
Apr
(2) |
May
(5) |
Jun
(6) |
Jul
(12) |
Aug
(22) |
Sep
(5) |
Oct
(7) |
Nov
(15) |
Dec
(5) |
2006 |
Jan
(60) |
Feb
(7) |
Mar
(12) |
Apr
(7) |
May
(5) |
Jun
(14) |
Jul
(19) |
Aug
(21) |
Sep
(16) |
Oct
(2) |
Nov
(15) |
Dec
(3) |
2007 |
Jan
|
Feb
|
Mar
|
Apr
(24) |
May
|
Jun
(26) |
Jul
(12) |
Aug
(1) |
Sep
(7) |
Oct
(2) |
Nov
|
Dec
(1) |
2008 |
Jan
(4) |
Feb
(6) |
Mar
(4) |
Apr
(4) |
May
(5) |
Jun
(4) |
Jul
(4) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2009 |
Jan
|
Feb
(27) |
Mar
(20) |
Apr
(8) |
May
(1) |
Jun
(1) |
Jul
|
Aug
(3) |
Sep
(2) |
Oct
(1) |
Nov
|
Dec
|
2010 |
Jan
(3) |
Feb
(1) |
Mar
(3) |
Apr
|
May
|
Jun
(4) |
Jul
(7) |
Aug
(6) |
Sep
(7) |
Oct
(1) |
Nov
|
Dec
|
2011 |
Jan
|
Feb
(5) |
Mar
(5) |
Apr
(16) |
May
|
Jun
(6) |
Jul
(20) |
Aug
(10) |
Sep
(4) |
Oct
|
Nov
|
Dec
(7) |
2012 |
Jan
(5) |
Feb
|
Mar
(9) |
Apr
|
May
(6) |
Jun
(3) |
Jul
(1) |
Aug
|
Sep
|
Oct
(1) |
Nov
(5) |
Dec
(6) |
2013 |
Jan
|
Feb
|
Mar
(5) |
Apr
|
May
|
Jun
|
Jul
(2) |
Aug
(2) |
Sep
(3) |
Oct
(1) |
Nov
(1) |
Dec
|
2014 |
Jan
(5) |
Feb
|
Mar
|
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
(7) |
Sep
|
Oct
|
Nov
|
Dec
|
2015 |
Jan
|
Feb
|
Mar
|
Apr
(4) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(2) |
Nov
(7) |
Dec
|
2016 |
Jan
|
Feb
|
Mar
(4) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(11) |
Nov
|
Dec
|
2018 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(2) |
2019 |
Jan
(8) |
Feb
(17) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(3) |
Dec
|
2020 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(1) |
Dec
|
2021 |
Jan
(4) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2022 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
|
Dec
|
From: Kai R. <kai...@ar...> - 2005-01-15 08:46:06
|
Hi Derek, On Sat, 15 Jan 2005 00:24:26 -0500 you wrote: > I just released rssh version 2.2.3 to fix the problem detailed below. Thx. rssh 2.2.3 is running fine since this morning :) > Sorry for the slow response; I've had other priorities lately. Will you still maintain rssh or is the statement > Moreover he has other priorities and has lost interest in maintaining the > program. He has offered to assist anyone who would like to take over > maintainership of rssh. still valid? --=20 Ciao Kai WWW: http://kai.iks-jena.de/ Blog: http://rabenhorst.blogg.de/ OpenPGP: D6E995A0 Jabber: kr...@ja... |
From: Derek M. <co...@pi...> - 2005-01-15 05:24:50
|
I just released rssh version 2.2.3 to fix the problem detailed below. I haven't had time to update my website yet, and my Internet acess is quite limited these days (hence the terse announcement), so I probably won't get to that for a while. However, rssh 2.2.3 is available from the sourceforge.net site: http://sourceforge.net/projects/rssh All users of rssh should update to the latest release. The rssh homepage is here: http://www.pizzashack.org/rssh Sorry for the slow response; I've had other priorities lately. DM On Thu, Dec 02, 2004 at 01:51:43PM +0000, Jason Wies wrote: > Vulnerable applications: > > rssh > All versions > All operating systems > scponly > All versions > All operating systems > > Not vulnerable: > > Discussion: > > rssh and scponly are restricted shells that are designed to allow execution > only of certain preset programs. Both are used to grant a user the ability > to transfer files to and from a remote host without granting full shell > access. Due to the fact that most of the preset programs offer options that > execute other programs, arbitrary command execution on the remote host is > possible. > > rssh allows any of five predefined programs to be executed on the remote > host depending on the configuration. Those that are known to be vulnerable > in combination with the techniques described in this posting are marked with > an asterisk. > - scp* > - sftp-server > - cvs > - rdist* > - rsync* > > scponly allows a number of predefined programs to be executed on the remote > host depending on compile-time options. Those that are known to be > vulnerable when used with scponly: > - scp > - rsync > - unison (*untested) > > The program execution options that these programs offer: > > rdist -P <program> > rsync -e <program> > scp -S <program> > unison -rshcmd <program> > unison -sshcmd <program> > > These options allow the user to specify the location of the shell to use > when connecting to the remote host. No restriction is placed on what > programs may be specified by these options, and rssh and scponly do not > filter these options out. The end result is that although a user may be > restricted by rssh or scponly to running e.g. only /usr/bin/scp, they can > in fact execute any program using /usr/bin/scp -S <program>. > > The problem is compounded when you recognize that the main use of rssh and > scponly is to allow file transfers, which in turn allows a malicious user to > transfer and execute entire custom scripts on the remote machine. > > rssh with sftp-server does not appear to be vulnerable. rssh with cvs is > also not vulnerable using these techniques. However, it is quite probable > that a malicious user could check out a carefully crafted CVS repository and > execute arbitrary commands using CVS's hooks interface. > > Examples: > > ssh restricteduser@remotehost 'rsync -e "touch /tmp/example --" localhost:/dev/null /tmp' > > scp command.sh restricteduser@remotehost:/tmp/command.sh > ssh restricteduser@remotehost 'scp -S /tmp/command.sh localhost:/dev/null /tmp' > > Solution: > > There are no workarounds for this problem. > > I have talked with the author of rssh, Derek Martin. He is currently > indisposed for an indefinite period of time due to changing countries and > having no permanent home at the present moment. Moreover he has other > priorities and has lost interest in maintaining the program. He has offered > to assist anyone who would like to take over maintainership of rssh, but he > does not intend to provide a fix for the current problem. Given this fact, > I would strongly recommend against using rssh at this time. > > The author of scponly, Joe Boyle, has prepared a new release, version 4.0, > that addresses the current problem. > > Distributor updates have been coordinated with this posting and should be > available soon. > > I think the long-term solution for those needing a highly secure restricted > shell is to allow granular configuration by administrators of which options > and arguments, if any, are allowed to be specified for which programs. In > the most restricted case entire command lines would be stored on the remote > host and the client would be allowed only to select from the list of > available command lines. I'm not aware of any software that offers these > capabilities today. > > References: > http://www.pizzashack.org/rssh/index.shtml > http://www.sublimation.org/scponly/ > > > ------------------------------------------------------- > SF email is sponsored by - The IT Product Guide > Read honest & candid reviews on hundreds of IT Products from real users. > Discover which products truly live up to the hype. Start reading now. > http://productguide.itmanagersjournal.com/ > _______________________________________________ > rssh-discuss mailing list > rss...@li... > https://lists.sourceforge.net/lists/listinfo/rssh-discuss -- Derek D. Martin http://www.pizzashack.org/ GPG Key ID: 0x81CFE75D |
From: Derek M. <co...@pi...> - 2005-01-15 05:02:16
|
On Wed, Dec 01, 2004 at 03:23:46PM -0500, John M. L. wrote: > The new cygwin dll 1.5.12-1 released on Nov 11th includes wordexp.h in the > source. Has anyone experimented with rssh and cygwin lately? How, if at > all, will that effect the install of rssh on cygwin? POSIX compliance? > > John M Lauck > Well, John, I don't have any Cygwin systems, but that ought to make it work. Did you try it? There's nothing else in rssh which is particularly troublesome... -- Derek D. Martin http://www.pizzashack.org/ GPG Key ID: 0x81CFE75D |
From: SHIROYAMA T. <sh...@fr...> - 2005-01-14 06:50:53
|
Hello. I succeeded to make rssh-2.2.2 on Mac OS X 10.3.7. OS X doesn't have wordexp(), so I ported this function from FreeBSD 5 . FreeBSD 5's wordexp() use hidden undocumented function in /bin/sh, so I wrote a little helper command to work with /bin/sh on OS X. 1. how to build. My wordexp() is here. http://www.eternal.nest.or.jp/%7Eshiro/tmp/libwordexp.tar.gz Get this, do './configure', 'make' and 'sudo make install ' . ( I only use configure script to move install directory. It check functions, headers, and so on. but not apply source codes. ) Next, expand rssh-2.2.2 archive, change directory and do following command. env CPPFLAGS="-I/usr/local/include" CFLAGS="-I/usr/local/include" \ LDFLAGS="-L/usr/local/lib" LIBS="-lwordexp" ./configure Then do 'make' and 'sudo make install'. 2. how to use . At first, create user with Account Panel on System Preferences. Then execute following command. sudo niutil -destroyprop . /users/rsshuser shell sudo niutil -createprop . /users/rsshuser shell /usr/local/bin/rssh Thanks. --- SHIROYAMA Takayuki : pur...@ma... / sh...@fr... |
From: Derek M. <co...@pi...> - 2004-12-11 03:09:58
|
On Sat, Dec 04, 2004 at 01:21:20PM +0100, Jesus Climent wrote: > Hi. > > I have read about the sec vulnerability and some claim that you are not > planing to release a new version with the bug solved. Hello Jesus, Well.... I am planning to release a fix; I just don't know when that will be. Right now, I simply don't have time. FWIW, all that needs to be done is to look for a specific option in the command line, and strip it out. The work shouldn' be that tough, but I don't have time to work on it right now. Actually I was kind of hoping someone would be interested in taking over the mainenance of rssh, but no one has stepped up to offer to do that. Oh well... So I don't have a date, real or imagined, for a fixed release. Probably it would be several months. -- Derek D. Martin http://www.pizzashack.org/ GPG Key ID: 0x81CFE75D |
From: Derek M. <co...@pi...> - 2004-12-11 02:42:40
|
On Mon, Dec 06, 2004 at 08:35:21PM +0100, Kai Raven wrote: > > rssh with sftp-server does not appear to be vulnerable. > > So i can assume that i'm secure, if i'm using rssh only with > sftp-server and the following options in the rssh.conf? Yes. -- Derek D. Martin http://www.pizzashack.org/ GPG Key ID: 0x81CFE75D |
From: Kai R. <kai...@ar...> - 2004-12-06 19:43:20
|
Hi Jason, On Thu, 2 Dec 2004 13:51:43 +0000 you wrote: > rssh with sftp-server does not appear to be vulnerable. So i can assume that i'm secure, if i'm using rssh only with sftp-server and the following options in the rssh.conf? #allowscp allowsftp #allowcvs #allowrdist #allowrsync user="sshuserN:027:00010:/pathto/chroot/home/sshuserN" -- Ciao Kai WWW: http://kai.iks-jena.de/ Blog: http://rabenhorst.blogg.de/ GnuPG-Key: 0xD6E995A0 Jabber: kr...@ja... |
From: Jason W. <ja...@xc...> - 2004-12-02 22:04:46
|
Vulnerable applications: rssh All versions All operating systems scponly All versions All operating systems Not vulnerable: Discussion: rssh and scponly are restricted shells that are designed to allow execution only of certain preset programs. Both are used to grant a user the ability to transfer files to and from a remote host without granting full shell access. Due to the fact that most of the preset programs offer options that execute other programs, arbitrary command execution on the remote host is possible. rssh allows any of five predefined programs to be executed on the remote host depending on the configuration. Those that are known to be vulnerable in combination with the techniques described in this posting are marked with an asterisk. - scp* - sftp-server - cvs - rdist* - rsync* scponly allows a number of predefined programs to be executed on the remote host depending on compile-time options. Those that are known to be vulnerable when used with scponly: - scp - rsync - unison (*untested) The program execution options that these programs offer: rdist -P <program> rsync -e <program> scp -S <program> unison -rshcmd <program> unison -sshcmd <program> These options allow the user to specify the location of the shell to use when connecting to the remote host. No restriction is placed on what programs may be specified by these options, and rssh and scponly do not filter these options out. The end result is that although a user may be restricted by rssh or scponly to running e.g. only /usr/bin/scp, they can in fact execute any program using /usr/bin/scp -S <program>. The problem is compounded when you recognize that the main use of rssh and scponly is to allow file transfers, which in turn allows a malicious user to transfer and execute entire custom scripts on the remote machine. rssh with sftp-server does not appear to be vulnerable. rssh with cvs is also not vulnerable using these techniques. However, it is quite probable that a malicious user could check out a carefully crafted CVS repository and execute arbitrary commands using CVS's hooks interface. Examples: ssh restricteduser@remotehost 'rsync -e "touch /tmp/example --" localhost:/dev/null /tmp' scp command.sh restricteduser@remotehost:/tmp/command.sh ssh restricteduser@remotehost 'scp -S /tmp/command.sh localhost:/dev/null /tmp' Solution: There are no workarounds for this problem. I have talked with the author of rssh, Derek Martin. He is currently indisposed for an indefinite period of time due to changing countries and having no permanent home at the present moment. Moreover he has other priorities and has lost interest in maintaining the program. He has offered to assist anyone who would like to take over maintainership of rssh, but he does not intend to provide a fix for the current problem. Given this fact, I would strongly recommend against using rssh at this time. The author of scponly, Joe Boyle, has prepared a new release, version 4.0, that addresses the current problem. Distributor updates have been coordinated with this posting and should be available soon. I think the long-term solution for those needing a highly secure restricted shell is to allow granular configuration by administrators of which options and arguments, if any, are allowed to be specified for which programs. In the most restricted case entire command lines would be stored on the remote host and the client would be allowed only to select from the list of available command lines. I'm not aware of any software that offers these capabilities today. References: http://www.pizzashack.org/rssh/index.shtml http://www.sublimation.org/scponly/ |
From: Jason W. <ja...@xc...> - 2004-12-02 17:43:10
|
Vulnerable applications: rssh All versions All operating systems scponly All versions All operating systems Not vulnerable: Discussion: rssh and scponly are restricted shells that are designed to allow execution only of certain preset programs. Both are used to grant a user the ability to transfer files to and from a remote host without granting full shell access. Due to the fact that most of the preset programs offer options that execute other programs, arbitrary command execution on the remote host is possible. rssh allows any of five predefined programs to be executed on the remote host depending on the configuration. Those that are known to be vulnerable in combination with the techniques described in this posting are marked with an asterisk. - scp* - sftp-server - cvs - rdist* - rsync* scponly allows a number of predefined programs to be executed on the remote host depending on compile-time options. Those that are known to be vulnerable when used with scponly: - scp - rsync - unison (*untested) The program execution options that these programs offer: rdist -P <program> rsync -e <program> scp -S <program> unison -rshcmd <program> unison -sshcmd <program> These options allow the user to specify the location of the shell to use when connecting to the remote host. No restriction is placed on what programs may be specified by these options, and rssh and scponly do not filter these options out. The end result is that although a user may be restricted by rssh or scponly to running e.g. only /usr/bin/scp, they can in fact execute any program using /usr/bin/scp -S <program>. The problem is compounded when you recognize that the main use of rssh and scponly is to allow file transfers, which in turn allows a malicious user to transfer and execute entire custom scripts on the remote machine. rssh with sftp-server does not appear to be vulnerable. rssh with cvs is also not vulnerable using these techniques. However, it is quite probable that a malicious user could check out a carefully crafted CVS repository and execute arbitrary commands using CVS's hooks interface. Examples: ssh restricteduser@remotehost 'rsync -e "touch /tmp/example --" localhost:/dev/null /tmp' scp command.sh restricteduser@remotehost:/tmp/command.sh ssh restricteduser@remotehost 'scp -S /tmp/command.sh localhost:/dev/null /tmp' Solution: There are no workarounds for this problem. I have talked with the author of rssh, Derek Martin. He is currently indisposed for an indefinite period of time due to changing countries and having no permanent home at the present moment. Moreover he has other priorities and has lost interest in maintaining the program. He has offered to assist anyone who would like to take over maintainership of rssh, but he does not intend to provide a fix for the current problem. Given this fact, I would strongly recommend against using rssh at this time. The author of scponly, Joe Boyle, has prepared a new release, version 4.0, that addresses the current problem. Distributor updates have been coordinated with this posting and should be available soon. I think the long-term solution for those needing a highly secure restricted shell is to allow granular configuration by administrators of which options and arguments, if any, are allowed to be specified for which programs. In the most restricted case entire command lines would be stored on the remote host and the client would be allowed only to select from the list of available command lines. I'm not aware of any software that offers these capabilities today. References: http://www.pizzashack.org/rssh/index.shtml http://www.sublimation.org/scponly/ |
From: John M. L. <jo...@re...> - 2004-12-01 20:24:08
|
The new cygwin dll 1.5.12-1 released on Nov 11th includes wordexp.h in the source. Has anyone experimented with rssh and cygwin lately? How, if at all, will that effect the install of rssh on cygwin? POSIX compliance? John M Lauck |
From: Caprio, D. <Don...@ba...> - 2004-10-29 22:32:05
|
> Host X: Linux **** 2.4.9-e.48smp #1 SMP OpenSSH_3.1p1, SSH protocols 1.5/2.0, OpenSSL > Host Y: SunOS **** 5.8 Generic_108528-26 sun4u sparc SUNW,Ultra-5_10 ssh: F-Secure SSH 3.2.3 (build 14) on sparc-sun-solaris2.8 > Host Z: Linux dcaprio 2.4.21-15.0.3.ELsmp #1 SMP Tue Jun 29 18:04:47 OpenSSH_3.1p1, SSH protocols 1.5/2.0, OpenSSL > > I have a user account setup with a restricted shell (/bin/rbash) on host X > > I can scp or ssh from the OpenSSH host (Z) to OpenSSH client (host X) just fine. > > On F-secure host Y I generated a key, copied it to host X (openSSH) server, > converted the key for use by OpenSSH using ssh-keygen -i ... > > ssh and scp from the F-secure server (Y) to the OpenSSH server (X) works fine. > > When I changed the users shell on host X to use a restricted shell (/bin/rbash) ssh still works however > scp does not! The scp command displays no errors or warnings. > > Anybody have a clue why scp will not work with F-Secure when the OpenSSH client is using > a restricted shell? I haven't been able to try with F-secure at both ends. > > > > |
From: Derek M. <co...@pi...> - 2004-10-23 08:48:44
|
PIZZACODE SECURITY ALERT program: rssh risk: low[*] problem: string format vulnerability in log.c details: rssh is a restricted shell for use with OpenSSH, allowing only scp and/or sftp. For example, if you have a server which you only want to allow users to copy files off of via scp, without providing shell access, you can use rssh to do that. Additioanlly, running rsync, rdist, and cvs are supported, and access can be configured on a per-user basis using a simple text-based configuration file. The rssh homepage is here: http://www.pizzashack.org/rssh/ Florian Schilhabel has identified a format string bug which can allow an attacker to run arbitrary code from an account configured to use rssh. [*]In general the risk is low, as in most cases the user can only compromise their own account. The risk is mittigated by the fact that before this bug can be exploited, the user must log in successfully through ssh. This means that either the user is known to the system (and therefore the administrators), or that the system is probably already compromised. However, on some older systems with broken implementations of the setuid() family of functions, a root compromise may be possible with certain configurations of rssh. Specifically, if rssh is configured to use a chroot jail, it will exec() rssh_chroot_helper, which must be setuid root in order to call chroot(). Normally, rssh_chroot_helper calls setuid(getuid()) and drops privileges before any of the logging functions are called, making a root compromise impossible on most systems. However, some older systems which handle saved UIDs improperly may be vulnerable to a root compromise. Linux in particular is not vulnerable to this, nor should modern POSIX-compliant Unix variants be. POSIX defines that the setuid() system call will set all UIDs (UID, saved UID, and effective UID) the specified UID if it is called with root privileges. Therefore in general, a root compromise is not possible, and I am not specifically aware of any systems on which one is possible. The 2.2.2 release of rssh fixes this string format vulnerability. I have also gone over the code to make sure that no other such vulnerabilities exist. In addition to fixing this problem, rssh contains some new code to help identify certain problems for debugging problems when rssh fails. Additional logging of error conditions is performed. -- Derek D. Martin http://www.pizzashack.org/ GPG Key ID: 0x81CFE75D |
From: Jonathan D. <de...@te...> - 2004-09-21 15:12:27
|
As a followup to my original post and subsequent developments on the Solaris thread mentioned in it: Chrooting rssh 2.2.1 now works for me under FreeBSD 5.2.1. The fix here as well was to add a shell (adding /bin/sh did it for me) to the chroot. Also a dev/null. My more verbose blatherings on the whole process can be found in: http://www.techno-obscura.com/~delgado/notes/fbsd-rsshChroot.html A big thanks to everyone involved who helped in digging up this simple solution. -Jonathan On Thu, Jul 22, 2004, I wrote: > Hi, I am having a problem with chrooting 2.2.1 under FreeBSD 5.2.1 > that seems similar to that in the ongoing thread about chroot under > Solaris 9 (http://sourceforge.net/mailarchive/forum.php?thread_id=4992072&forum_id=33294). > > I have had 2.1.1 running succesfully with chroot (rssh built from > the FreeBSD ports collection), and then made the move to 2.2.1 > (built from source). I have updated my rssh.conf and regular non- > chroot usage is fine, but when I try to connect to a chroot the > connection gets dropped. An error message is logged: > > Jul 22 15:03:30 myhost rssh_chroot_helper[89019]: error expanding arguments for user (null) > > For kicks I applied the patch provided in the Solaris 9 thread. > The error now logged is: > > Jul 22 15:22:32 myhost rssh_chroot_helper[90788]: wordexp() bad syntax > > Any thoughts on this? > > -Jonathan > > > ------------------------------------------------------- > This SF.Net email is sponsored by BEA Weblogic Workshop > FREE Java Enterprise J2EE developer tools! > Get your free copy of BEA WebLogic Workshop 8.1 today. > http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click > _______________________________________________ > rssh-discuss mailing list > rss...@li... > https://lists.sourceforge.net/lists/listinfo/rssh-discuss |
From: Derek M. <co...@pi...> - 2004-09-18 03:03:43
|
On Wed, Sep 15, 2004 at 10:03:37PM -0400, Paul wrote: > I've just my entire /lib directory to my chroot jail, and now it works. > Obviously I have lots of files in there I don't need, and I haven't > figured out what it was that I'm missing yet. Try running the script to build a chroot jail. It's in the source tarball, or it's in /usr/share/doc/rssh-<version> if you installed the rpm. > Though this still brings up my original question. Is it possible to log > the failure, when an executable fails due to a missing library? No. Control has passed from rssh at that point, so there's no way to log the problem. > Thanks for writing this. It's just what I need. :) -- Derek D. Martin http://www.pizzashack.org/ GPG Key ID: 0x81CFE75D |
From: Paul <rss...@bl...> - 2004-09-16 02:03:54
|
Hello.. again. Sorry for all the posts. Been fiddling with this all day, and finally I've got it working. I've just my entire /lib directory to my chroot jail, and now it works. Obviously I have lots of files in there I don't need, and I haven't figured out what it was that I'm missing yet. Though this still brings up my original question. Is it possible to log the failure, when an executable fails due to a missing library? Thanks for writing this. It's just what I need. Regards, Paul |
From: Paul <rss...@bl...> - 2004-09-16 01:36:01
|
Forgot to mention.. I've also copied over my passwd file, ld.so.* and nsswitch.conf files. Paul |
From: Paul <rss...@bl...> - 2004-09-16 01:27:56
|
Hello, I'm trying to get rssh installed on my system. I've got it working without chroot, to allow only sftp connections, but I'm having problems getting chroot to work. (I'm running on Slackware, with 2.4.26 kernel.) Right now, in my rssh.conf file, the only changes I've made are to enable sftp, and to change the chrootpath to /usr/local/chroot, with no per-user settings. Instead, I've only got one user on my machine with rssh set as the login shell. I've created my /usr/local/chroot directory, with an appropriate home directory for my user (created relative to the chroot dir). I've also created directories and copied over rssh, scp, rssh_chroot_helper and sftp-server, duplicating their original locations in my root jail directory. After that, I did the same with the dependant libraries for each of these executables. I think that covers everything that needs to be done? I've also restarted my syslogd, also specifying the dev/log directory from within my chroot directory. Something is clearly still wrong, because when I sftp in, the connection is immediately closed. What is written to my logs is: Sep 15 20:00:51 box sshd[20006]: Accepted password for xmruser from x.x.x.x port 36732 ssh2 Sep 15 20:00:51 box sshd[20008]: subsystem request for sftp Sep 15 20:00:51 box rssh[20009]: setting log facility to LOG_USER Sep 15 20:00:51 box rssh[20009]: allowing sftp to all users Sep 15 20:00:51 box rssh[20009]: setting umask to 022 Sep 15 20:00:51 box rssh[20009]: chrooting all users to /usr/local/chroot Sep 15 20:00:51 box rssh[20009]: chroot cmd line: /usr/local/libexec/rssh_chroot_helper "/usr/local/chroot" 2 "/" /usr/local/libexec/sftp-server Sep 16 00:00:51 box rssh_chroot_helper[20009]: new session for user, UID=2001 My problem now is, with what I see in the logs, I don't seem to have anything to go on. If one of my executables is failing to execute because of missing libraries, is it possible to have an error message logged somewhere? Regards, Paul |
From: <el...@on...> - 2004-08-20 15:44:49
|
Hi all! Maybe you remember my problem, where I always get the "forbidden command" error when trying to use RSSH+SFTP+CHROOT on my Debian system. Now I primitively debuged rssh a bit. It was a complete chance, that I could make rssh work. I don't know why it is working now, but at least, i= t does. In the main.c.in file, in the main(), I found the line, where rssh fails for me. it was the line: if ( !(argvec =3D build_shell_args(uinfo, &opts, argv[2], &cmd)) = ) fail(opts.shell_flags, argc, argv); At this point rssh called the fail() in util.c whatever I did. So I wante= d to see if argvec and build_shell_args why not equal. I'm not very bright = @ c, but I assumed that the following would work: /* get the arguments for execv() */ log_msg("ET: %s , %s", argvec, build_shell_args(uinfo, &opts, argv[2], &cmd)); if ( !(argvec =3D build_shell_args(uinfo, &opts, argv[2], &cmd)) = ) fail(opts.shell_flags, argc, argv); After this I did a make clean make make install At my greatest surprise, next time I tried to login, it simply WORKED!!! chroot was fine, and so... I looked at the logs immediately. The user.log told me: Aug 20 17:03:03 kistestver rssh[29124]: setting umask to 022 Aug 20 17:03:03 kistestver rssh[29124]: line 49: configuring user temp Aug 20 17:03:03 kistestver rssh[29124]: setting temp's umask to 011 Aug 20 17:03:03 kistestver rssh[29124]: allowing sftp to user temp Aug 20 17:03:03 kistestver rssh[29124]: chrooting temp to /tmp Aug 20 17:03:03 kistestver rssh[29124]: chroot cmd line: /usr/local/rssh/libexec/rssh_chroot_helper "/tmp" 2 "/" /usr/libexec/sftp-server Aug 20 17:03:03 kistestver rssh[29124]: ET: (null) , \200=BD^D^H\230.^E^H\236=B2^D^H=B0'^E^H=A5=F2=FF=BF Aug 20 17:03:03 kistestver rssh[29124]: chroot cmd line: /usr/local/rssh/libexec/rssh_chroot_helper "/tmp" 2 "/" /usr/libexec/sftp-server As I have seen the line, containing "ET:" (this comes from the first, capital letters of my name) I realised, that this is the recompiled version. I really don't want to get my old C book down of the shelf and see if the call of the log_msg() function were ok or not (since the parameters are char**), but at least worked. Derek must know better, what has happened. ;) Anyway, I tried to make anything back, I've deleted the cahnges I have made, again make clean make and make install, but then again not worked. I've also tried calling build_shell_args() on it's own (maybe it not set some kind of variable on first call) but in that case it was also not working. The only, working "solution" was calling the log_msg() on the wa= y I did. Since rssh is working now, I'm happy, but I would be really courious, that WHY??? Thank you in advance. |
From: <jg...@ar...> - 2004-08-11 09:53:33
|
Hello, Thanks for the suggestion. I traced a testprogram that simply calls wordexp= () with "truss -f" and learned that /usr/bin/ksh93 is executed (an enhance= d ksh). The relevant shared libraries were already in place. Adding this bi= nary to the chroot-jail solves the problem, rssh runs fine now. my chroot environment for AIX 5.2 sftp is quite sparse: ./opt/freeware/lib/libcrypto.a ./usr/sbin/sftp-server ./usr/lib/libc.a ./usr/lib/libcrypt.a ./usr/bin/ksh93 Greetings Joachim Gann Arcor-DSL: jetzt ohne Einrichtungspreis einsteigen oder wechseln Sie sparen 99,95 Euro. Arcor-DSL ist in vielen Anschlussgebieten verf=FCgbar. http://www.arcor.de/home/redir.php/emf-dsl-1 |
From: Derek M. <co...@pi...> - 2004-08-11 03:27:21
|
On Tue, Aug 10, 2004 at 04:38:34PM -0400, Marty Saletta wrote: > > Hi Derek- > > Okay, some good news! With Sun's help, I've got rssh 2.2.1 > working on Solaris 9. Sun looked at the code for their > wordexp(), and here's what they suggested today: Fantastic. As soon as I have time, I'll update the documentation and the FAQ on the website. > > >The wordexp() function is expecting a shell to exist at one of the two > >hard-coded locations: > > > >/bin/ksh To Joachim Gann: please try to add the system's default shell to your chroot jail, and see if that helps. I'm not sure what it would be on AIX, but you should try at least these: /bin/sh /usr/bin/sh /bin/ksh /usr/bin/ksh Make sure that if your platform doesn't link the shell statically (some do) that you also copy any libraries that it needs into the chroot jail. -- Derek D. Martin http://www.pizzashack.org/ GPG Key ID: 0x81CFE75D |
From: Marty S. <ma...@ca...> - 2004-08-10 21:18:48
|
In an effort to give back, here's what I've done as far as setting up a chrooted environment for rssh 2.2.1 to play nicely with Solaris 9. There is not alot of files here, but since Derek is more versed in the Linux side of things, perhaps I could help fellow Solaris users get a chroot environment up and going for rssh. Usual disclaimer: this works for me. I've tested it on only a few different Sun hardware platforms, all Solaris 9 though. I'm running a syslog hack to get Solaris syslog messages out of the chrooted environment, thus you may not need all of this for just rssh. I also use a custom build of OpenSSH, not Sun's ssh that ships with Solaris. I allow both scp and sftp access through rssh. Your milage may vary, blah blah. My chroot directory that includes rssh 2.2.1 has the following dirs/files in it: bin/ksh dev/conslog dev/log dev/null dev/syscon dev/zero etc/passwd etc/default/init usr/lib/ld.so.1 usr/lib/libaio.so.1 usr/lib/libc.so.1 usr/lib/libdl.so.1 usr/lib/libmd5.so.1 usr/lib/libmp.so.2 usr/lib/libnsl.so.1 usr/lib/libresolv.so.2 usr/lib/librt.so.1 usr/lib/libsocket.so.1 usr/lib/nss_files.so.1 usr/local/bin/scp usr/local/libexec/rssh_chroot_helper usr/local/libexec/sftp-server usr/local/platform/<platform>/lib/libc_psr.so.1 usr/local/platform/<platform>/lib/libmd5_psr.so.1 usr/share/lib/zoneinfo/US/Eastern usr/xpg4/bin/sh home/<user_dirs> And that's it. Remember that when patches are applied to copy them to this area too. -Marty |
From: Marty S. <ma...@ca...> - 2004-08-10 20:38:43
|
Hi Derek- Okay, some good news! With Sun's help, I've got rssh 2.2.1 working on Solaris 9. Sun looked at the code for their wordexp(), and here's what they suggested today: >The wordexp() function is expecting a shell to exist at one of the two >hard-coded locations: > >/bin/ksh > >or > >/usr/xpg4/bin/sh > > You are apparently using chroot, which means that you have to either >have a ./bin or a ./usr/xpg4/bin directory under the directory you are >defining as the root of their chroot environment. What is almost >assuredly the case is that neither of these paths exist under your >chroot directory, and so there is no shell visible to wordexp() to exec. Taking their advice, I added these executables to my chrooted environment, and it worked. It seems that in my very limited testing so far that the ksh is more valuable, since if it doesn't exist I get the same "error expanding arguments for user ..." message in the logs. I'm not 100% sure the /usr/xpg4/bin/sh is required, but I'm not going to move it anytime soon. I'm going to continue to test this, and I'll report anything strange to this list. Much thanks to Derek for helping with this issue. The test code given to me proved to be exactly what was needed, as this is also from Sun's message to me today: > Here is our answer on the issue. The only way that wordexp() can >return 127 is if the execvp() of the shell fails. The wordexp() >function forks and execs a shell which does the job of expanding the >string. If the exec fails, it will return 127. Without that test code, I'm not sure we'd have an answer. It was a shell just as you suspected, just not sh...excellent work! -Marty On Wed, 11 Aug 2004, Derek Martin wrote: > On Mon, Jun 28, 2004 at 04:44:28PM -0400, Marty Saletta wrote: > > > > Hi Derek- > > > > Thanks for the reply. I tried the suggestions below- no luck. > > Actually, I already had /dev/zero and /dev/null in place > > in the chrooted environment to support syslog reporting, so I > > tried copying sh to both /usr/bin and /bin of the chroot jail, > > neither of which worked. > > I just realized that it could still be (/usr)/bin/sh... You'll need > to check what libraries the shell is linked against, and make sure > that all of those are present in the chroot jail. For example, on > Linux (which does not exhibit this problem), /bin/bash is linked > against libtermcap, which is not needed by any of the other (r)ssh > files in the chroot jail. > > I still think this is the most likely culprate. > > -- > Derek D. Martin > http://www.pizzashack.org/ > GPG Key ID: 0x81CFE75D > > |
From: <el...@on...> - 2004-08-10 16:38:11
|
>Hy. > Well, one suggestion is to try 2.1.1 instead. There's a minor Debian's distro contains the same, and I don't want to use that, (by the way I have already tried that version) anyway I always compile system-critical components from source. I have grsecurity installed. Mayb= e that? > rssh package... You want to make sure you don't have that installed, > as it likely would screw things up. I did not install it, see the reason above. > >> I've enabled only one, per-user basis setting for rssh: >> user=3Dtemp:022:00010:"/var/www" > > Interesting... In your logs: okay then, I post the full one. I tried once again from scratch, and I have still the same problem. (maybe I need to set up a chroot environment in /var/www? (with /var/www the root path?)) the /usr/libexec/sftp-server is being run with the chrooted user privileges, instead of rssh? Aug 10 17:44:17 kistestver rssh[28416]: setting umask to 022 Aug 10 17:50:46 kistestver rssh[21037]: allowing sftp to all users Aug 10 17:50:46 kistestver rssh[21037]: setting umask to 022 Aug 10 17:50:46 kistestver rssh[21037]: line 49: configuring user temp Aug 10 17:50:46 kistestver rssh[21037]: setting temp's umask to 011 Aug 10 17:50:46 kistestver rssh[21037]: allowing sftp to user temp Aug 10 17:50:46 kistestver rssh[21037]: chrooting temp to /var/www Aug 10 17:50:46 kistestver rssh[21037]: user temp attempted to execute forbidden commands Aug 10 17:50:46 kistestver rssh[21037]: command: /usr/libexec/sftp-server > What happens if you run the following commands: > > $ rssh -v > $ which rssh kistestver:/home/eliast# rssh -v rssh 2.2.1 (c) 2002-3 Derek D. Martin <rssh-discuss at lists dot sourceforge dot net> kistestver:/home/eliast# which rssh /usr/local/bin/rssh kistestver:/home/eliast# apt-get remove rssh Reading Package Lists... Done Building Dependency Tree... Done Package rssh is not installed, so not removed 0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded. kistestver:/home/eliast# > My suggestion, if nothing reveals itself as the solution, is to make > sure you've removed all traces of any existing installations of rssh, I'm sure. > and re-install. Maybe that will help. Not help. :( my sftp-server has 100755 (octal permissions) root:root Is it possible to somehow run strace on rssh? (while the remote login happens, strace would create a logfile... I use strace not too often, thus, I don't know if this can be done, so we could see why it can't open what is there...) I've already tried, what I have written on the beginning of this letter, so I copied needed libs by sftp-server into the /var/www (of course, kept dir sctructure). I've have a good script for that. I attach it, someone might need. lddcopy.sh: #!/bin/sh ##################################################################### # # Initialize - handle command-line args, and set up variables and such. # # $1 is the directory to make the root of the chroot jail (required) # $2 is the ELF binary that have to be checked (required) # $3, if given, is the user who should own the jail (optional) # $4, if given, is the permissions on the directory (optional) # if [ -z "$1" ]; then echo "`basename $0`: error parsing command line" >&2 echo " You must specify a directory to use as the chroot jail." = >&2 exit 1 fi jail_dir=3D"$1" if [ -n "$3" ]; then owner=3D"$3" fi if [ -n "$4" ]; then perms=3D"$4" fi ##################################################################### # # copy to the jail # # now make the directory if [ ! -d "$jail_dir" ]; then echo "Creating root jail directory." mkdir -p "$jail_dir" if [ $? -ne 0 ]; then echo " `basename $0`: error creating jail directory." >&= 2 echo "Check permissions on parent directory." >&2 exit 2 fi fi if [ -n "$owner" -a `whoami` =3D "root" ]; then echo "Setting owner of jail." chown "$owner" "$jail_dir" if [ $? -ne 0 ]; then echo " `basename $0`: error changing owner of jail directory." >&2 exit 3 fi else echo -e "NOT changing owner of root jail. \c" fi if [ -n "$owner" -a `whoami` =3D "root" ]; then echo "Setting permissions of jail." chmod "$perms" "$jail_dir" if [ $? -ne 0 ]; then echo " `basename $0`: error changing perms of jail directory." >&2 exit 3 fi else echo -e "NOT changing perms of root jail. \c" if [ `whoami` !=3D "root" ]; then echo "You are not root." else echo fi fi ##################################################################### # # identify and copy libraries needed in the jail # for prog in $2; do echo "Copying libraries for $prog." libs=3D`ldd $prog | tr -s ' ' | cut -d' ' -f3` for lib in $libs; do mkdir -p "$jail_dir$(dirname $lib)" echo -e "\t$lib" cp "$lib" "$jail_dir$lib" done done echo Done. |
From: Derek M. <co...@pi...> - 2004-08-10 15:54:36
|
On Tue, Aug 10, 2004 at 05:37:12PM +0200, =C9li=E1s Tam=E1s Istv=E1n wrote: > Hi! I compiled rssh 2.2.1 for my Debian Sarge system with kernel 2.6.7. > But I can't make it work.=20 Well, one suggestion is to try 2.1.1 instead. There's a minor security issue with that version, but it's really trivial for almost everybody. Another thing worth mentioning is that Debian does have an rssh package... You want to make sure you don't have that installed, as it likely would screw things up. > I've enabled only one, per-user basis setting for rssh: > user=3Dtemp:022:00010:"/var/www" Interesting... In your logs: > Aug 6 14:47:04 kistestver rssh[24731]: allowing sftp to all users > Aug 6 14:47:04 kistestver rssh[24731]: setting umask to 022 > Aug 6 14:47:04 kistestver rssh[24731]: user temp attempted to > execute forbidden commands > Aug 6 14:47:04 kistestver rssh[24731]: command: /usr/libexec/sftp-server There's no indication of rssh having read the per-user configuration for user temp. You should see that. This leads me to think that rssh didn't read the version of the config file that you added this to. I have no idea why that could be though; you'll have to figure that out for yourself. Perhaps you made a mistake with your configure options... I can't think of any other possibilities. was there already a version of rssh installed on the system? The other problem is that rssh /IS/ allowing sftp, but thinks that sftp-server is not an allowed command. That just doesn't happen, as far as I'm aware. I'm again inclined to think that there's something very strange with your installation of rssh. Maybe I should add some code to emit what rssh thinks are the right paths for things... What happens if you run the following commands: $ rssh -v $ which rssh My suggestion, if nothing reveals itself as the solution, is to make sure you've removed all traces of any existing installations of rssh, and re-install. Maybe that will help. --=20 Derek D. Martin http://www.pizzashack.org/ GPG Key ID: 0x81CFE75D |
From: Derek M. <co...@pi...> - 2004-08-10 15:41:14
|
On Mon, Jun 28, 2004 at 04:44:28PM -0400, Marty Saletta wrote: > > Hi Derek- > > Thanks for the reply. I tried the suggestions below- no luck. > Actually, I already had /dev/zero and /dev/null in place > in the chrooted environment to support syslog reporting, so I > tried copying sh to both /usr/bin and /bin of the chroot jail, > neither of which worked. I just realized that it could still be (/usr)/bin/sh... You'll need to check what libraries the shell is linked against, and make sure that all of those are present in the chroot jail. For example, on Linux (which does not exhibit this problem), /bin/bash is linked against libtermcap, which is not needed by any of the other (r)ssh files in the chroot jail. I still think this is the most likely culprate. -- Derek D. Martin http://www.pizzashack.org/ GPG Key ID: 0x81CFE75D |