Re: [off-topic?] Chrooting ssh/telnet users?
On Mon, Oct 29, 2001 at 01:51:48PM +0100, Christian Kurz wrote: On 29/10/01, Emmanuel Lacour wrote: On Mon, Oct 29, 2001 at 09:48:00AM +1300, Stephen Andrew wrote: What about a package ssh-chroot in debian? I think the pam module is more interesting as it can be aplied to other thinks, but I tried it and was unable to make it working (I'm not a pam master!!). What do you exactly mean unable to make it working? Did you change /etc/pam.d/ssh(d?) to contain a line like this: |session required /lib/security/pam_chroot.so debug onerr=fail If yes, did you check logfiles for any hints? If yes, what kind of error message did you get? Does ssh -v show any helpful info? I haven't used that pam-module so far, but I don't think that it will be so difficult to get it working. Don't be anxious, I'm sure it works, I just tried to use it five minutes, when I was having problem with ssh+chroot patch (see a thread initiated by me one or two month ago in this list). -- Easter-eggsSpécialiste GNU/Linux 44-46 rue de l'Ouest - 75014 Paris - France - Métro Gaité Phone: +33 (0) 1 43 35 00 37- Fax: +33 (0) 1 41 35 00 76 mailto:[EMAIL PROTECTED] -http://www.easter-eggs.com PGP signature
Re: [off-topic?] Chrooting ssh/telnet users?
On Mon, Oct 29, 2001 at 09:48:00AM +1300, Stephen Andrew wrote: There is a chroot patch for the potato openssh-1.2.3 source in /contrib however it appears to be broken. I have created a modified diff for the Debian package source which will apply the patch correctly and build an ssh_1.2.3chroot1-9.3 package. --Snip--- There's the same problem in all versions of openssh from debian, you must apply the chroot patch by hand (maybe because debian openssh is patched) I've got also a version of openssh 2.9p2-6 from sid recompiled for potato with the chroot support...it works for me (with openssl 095a recompiled by jones???) (I do also some little modifications: no suid by default in debconf and no permitrootlogin by default. deb http://people.easter-eggs.org/~manu/debian/ ssh/ What about a package ssh-chroot in debian? I think the pam module is more interesting as it can be aplied to other thinks, but I tried it and was unable to make it working (I'm not a pam master!!). -- Easter-eggsSp?cialiste GNU/Linux 44-46 rue de l'Ouest - 75014 Paris - France - M?tro Gait? Phone: +33 (0) 1 43 35 00 37- Fax: +33 (0) 1 41 35 00 76 mailto:[EMAIL PROTECTED] -http://www.easter-eggs.com pgpHtCGgnKM5h.pgp Description: PGP signature
Re: [off-topic?] Chrooting ssh/telnet users?
On 29/10/01, Emmanuel Lacour wrote: On Mon, Oct 29, 2001 at 09:48:00AM +1300, Stephen Andrew wrote: What about a package ssh-chroot in debian? I think the pam module is more interesting as it can be aplied to other thinks, but I tried it and was unable to make it working (I'm not a pam master!!). What do you exactly mean unable to make it working? Did you change /etc/pam.d/ssh(d?) to contain a line like this: |session required /lib/security/pam_chroot.so debug onerr=fail If yes, did you check logfiles for any hints? If yes, what kind of error message did you get? Does ssh -v show any helpful info? I haven't used that pam-module so far, but I don't think that it will be so difficult to get it working. Christian -- Debian Developer (http://www.debian.org) 1024/26CC7853 31E6 A8CA 68FC 284F 7D16 63EC A9E6 67FF 26CC 7853 pgpQUXya11HR8.pgp Description: PGP signature
Re: [off-topic?] Chrooting ssh/telnet users?
At 1:02 Uhr +0200 27.10.2001, Javier Fernández-Sanguino Peña wrote: Umm... couldn't you have a restricted environment but with commands hard-linked in it to the proper ones and restricting thoroughly the hard links? (only rX, no w bits) The problem is how to do this automatically (and not checking dynamic dependencies one by one...) I've actually begun to write such a thing. Tough it seems I don't have enough time to finish it in the near future. What I've begun writing is a set of perl scripts that - allow to sync one file tree into another by creating hard links where possible (same filesystem, binary is not suid) or copy the file (and remove suid bits) if not. - script to parse strace output. - you can run whatever you need in the chroot under strace, then let the script extract all files that have been opened. This way you get exactly which files are needed in the chroot. I've written this with a slightly different use of chroot in mind: the setup of sandbox environments, where you (each user) can run things like ICQ clients that he doesn't trust to be secure enough (thus potential hacks being limited to the chroot), but under his userid (so he can save his files etc.) Alternatively you could define a set of binaries and write a script iterating over them with ldd to extract all libraries needed, of course. Well regarding sandbox I've also a script (wrapper aroung the executable you want to run in the sandbox) in mind that copies/links the Xauthentification cookie over to the chroot, but unlinks it again as soon as the executable is up and has opened the X connection - if s.o. breaks in, he'll not be able to access the X session for key trapping etc. And there should be a script that checks whether there's a process running in the chroot before copying the X cookie over and if yes send it a SIGSTOP, to prevent a potential hacker daemon to open the X connection in the time frame where the cookie is there, and a SIGCONT after the cookie has been removed. If I only had enough time... BTW: I'm assuming that hard linked executables and libraries are loaded into RAM only once thus it doesn't create any overhead. Now I've heard that the linker is even able to detect when some library (?) has the (partially?) same content as another lib (or anything?) already loaded? Is this true? (If yes even copied libs wouldn't waste RAM, but I doubt it) Christian.
Re: [off-topic?] Chrooting ssh/telnet users?
On Mon, Oct 29, 2001 at 01:51:48PM +0100, Christian Kurz wrote: On 29/10/01, Emmanuel Lacour wrote: On Mon, Oct 29, 2001 at 09:48:00AM +1300, Stephen Andrew wrote: What about a package ssh-chroot in debian? I think the pam module is more interesting as it can be aplied to other thinks, but I tried it and was unable to make it working (I'm not a pam master!!). What do you exactly mean unable to make it working? Did you change /etc/pam.d/ssh(d?) to contain a line like this: |session required /lib/security/pam_chroot.so debug onerr=fail If yes, did you check logfiles for any hints? If yes, what kind of error message did you get? Does ssh -v show any helpful info? I haven't used that pam-module so far, but I don't think that it will be so difficult to get it working. Don't be anxious, I'm sure it works, I just tried to use it five minutes, when I was having problem with ssh+chroot patch (see a thread initiated by me one or two month ago in this list). -- Easter-eggsSp?cialiste GNU/Linux 44-46 rue de l'Ouest - 75014 Paris - France - M?tro Gait? Phone: +33 (0) 1 43 35 00 37- Fax: +33 (0) 1 41 35 00 76 mailto:[EMAIL PROTECTED] -http://www.easter-eggs.com pgpdiH4c1A2GS.pgp Description: PGP signature
Re: [off-topic?] Chrooting ssh/telnet users?
On Sat, Oct 27, 2001 at 01:02:45AM +0200, Javier Fernández-Sanguino Peña wrote: Umm... couldn't you have a restricted environment but with commands hard-linked in it to the proper ones and restricting thoroughly the hard links? (only rX, no w bits) The problem is how to do this automatically (and not checking dynamic dependencies one by one...) not if your luser's home directories are on a different partition from / and /usr like they should be. hard links can't have different permissions from the `originals' either btw, since with hard links neither is the `real' file; they both are. -- Ethan Benson http://www.alaska.net/~erbenson/ PGP signature
Re: [off-topic?] Chrooting ssh/telnet users?
Sunny Dubey [EMAIL PROTECTED] writes: The problem is, how can an admin restrict remote access from a given user (through telnet and/or sshd) in order to limit his moves inside the operating system. no idea if this will help but you could change their shells from bash to rbash (or bash -r) its pretty crappy however rbash seems to go out of its way to make life hard for someone - no ability to execute `cd' or `alias' at all, that sort of thing. It's not a lot of use if you want a complete chroot()ed environment with ability to do whatever they like within it; it's normally more useful to be able to organize your files into directories which rbash doesn't exactly help with. ~Tim -- The light of the world keeps shining, |[EMAIL PROTECTED] Bright in the primal glow |http://spodzone.org.uk/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [off-topic?] Chrooting ssh/telnet users?
well give credit to it to Vasil Kolev
/home/image.root is an image of what you want your users to have.
Ivan Dimitrov
System Administrator
Bastun Networks
On Sat, 27 Oct 2001, Javier [iso-8859-1] Fernández-Sanguino Peña wrote:
I would be interested only in the chroot patch. Is there any
reason you have not contributed it to openssh? Do you want me to do it?
Best regards
Javi
On Fri, Oct 26, 2001 at 05:24:13PM +0300, Ivan Dimitrov wrote:
recently i've worked on a small patch for openssh that chroots a user when
he logs in. it uses mysql for password auth. it is not posted anyware but
if you want it, send me a personal mail.
Ivan Dimitrov
System Administrator
Bastun Networks
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
--- orig-session.h Thu Oct 11 17:57:08 2001
+++ session.h Thu Oct 11 15:41:11 2001
@@ -32,5 +32,6 @@
void session_input_channel_req(int id, void *arg);
void session_close_by_pid(pid_t pid, int status);
void session_close_by_channel(int id, void *arg);
+#define AM_CHROOT
#endif
--- orig-session.c Thu Oct 11 17:53:53 2001
+++ session.c Fri Oct 12 15:38:24 2001
@@ -93,6 +93,12 @@
# include uinfo.h
#endif
+
+#ifdef AM_CHROOT
+#include sys/file.h
+#endif
+
+
/* types */
#define TTYSZ 64
@@ -162,6 +168,71 @@
static login_cap_t *lc;
#endif
+
+
+#ifdef AM_CHROOT
+/*
+ system() by W.Richard Stevens
+ */
+
+
+int
+system(const char *cmdstring) /* with appropriate signal handling */
+{
+ pid_t pid;
+ int status;
+ struct sigactionignore, saveintr, savequit;
+ sigset_tchldmask, savemask;
+
+ if (cmdstring == NULL)
+ return(1); /* always a command processor with Unix */
+
+ ignore.sa_handler = SIG_IGN;/* ignore SIGINT and SIGQUIT */
+ sigemptyset(ignore.sa_mask);
+ ignore.sa_flags = 0;
+ if (sigaction(SIGINT, ignore, saveintr) 0)
+ return(-1);
+ if (sigaction(SIGQUIT, ignore, savequit) 0)
+ return(-1);
+
+ sigemptyset(chldmask); /* now block SIGCHLD */
+ sigaddset(chldmask, SIGCHLD);
+ if (sigprocmask(SIG_BLOCK, chldmask, savemask) 0)
+ return(-1);
+
+ if ( (pid = fork()) 0) {
+ status = -1;/* probably out of processes */
+
+ } else if (pid == 0) { /* child */
+ /* restore previous signal actions reset signal mask */
+ sigaction(SIGINT, saveintr, NULL);
+ sigaction(SIGQUIT, savequit, NULL);
+ sigprocmask(SIG_SETMASK, savemask, NULL);
+
+ execl(/bin/sh, sh, -c, cmdstring, (char *) 0);
+ _exit(127); /* exec error */
+ } else {/* parent */
+ while (waitpid(pid, status, 0) 0)
+ if (errno != EINTR) {
+ status = -1; /* error other than EINTR from waitpid()
+*/
+ break;
+ }
+ }
+
+ /* restore previous signal actions reset signal mask */
+ if (sigaction(SIGINT, saveintr, NULL) 0)
+ return(-1);
+ if (sigaction(SIGQUIT, savequit, NULL) 0)
+ return(-1);
+ if (sigprocmask(SIG_SETMASK, savemask, NULL) 0)
+ return(-1);
+
+ return(status);
+}
+
+#endif
+
+
void
do_authenticated(Authctxt *authctxt)
{
@@ -1049,6 +1120,12 @@
#endif /* WITH_IRIX_ARRAY */
#endif /* WITH_IRIX_JOBS */
+#ifdef AM_CHROOT
+ char *mounting,*buff;
+int fd0,n,num;
+#endif
+
+
/* remove hostkey from the child's memory */
destroy_sensitive_data();
@@ -1127,6 +1204,79 @@
*/
do_pam_setcred(0);
# endif /* USE_PAM */
+# ifdef AM_CHROOT
+ if (pw-pw_gid == 888)
+ {
+ mounting=(char *) malloc(1024);
+
+snprintf(mounting,1024,/var/run/sshd/%s.mount,pw-pw_name);
+ fd0=open(mounting,O_RDWR|O_CREAT|O_EXCL,S_IRUSR
+|S_IWUSR);
+ if ( chdir(/home/sessions)!=0)
+ {
+ perror(Chdir to session dir failed);
+ exit(1);
+ }
+ if(fd0 != -1 )
+ {
+ flock(fd0,LOCK_EX);
+
RE: [off-topic?] Chrooting ssh/telnet users?
There is a chroot patch for the potato openssh-1.2.3 source in /contrib however it appears to be broken. I have created a modified diff for the Debian package source which will apply the patch correctly and build an ssh_1.2.3chroot1-9.3 package. Email me if you would like the diff. As has been well covered in this thread you will need to create a chroot jail which has all the executables your chroot user requires as well as the libraries the executables rely on. There are many ways to acheive this. For a very small chrooted environment (i.e. bash, cp, scp, ls, mv etc.) I generally create this manually by copying the executables into the new structure then running ldd on them to identify the libraries. For a larger chroot environment you may want to look at dbootstrap. You will have to manually maintain your chroot (upgrading executables/security updates) unless you install APT into the chroot. I generally don't. Regards, -- Andrew J. Stephen Phone +64 4 496 4484 Team Leader, Network Operations Mobile +64 25 582 304 New Zealand PostFax+64 4 496 4914 The important thing about standards is to have them. -- Bruce Schneier, creator of the Twofish algorithm -Original Message- From: Javier Fernández-Sanguino Peña [mailto:[EMAIL PROTECTED]] Sent: Saturday, 27 October 2001 02:15 To: [EMAIL PROTECTED] Subject: [off-topic?] Chrooting ssh/telnet users? I have been asked for this and I was trying to figure out how to do it (would document it later on in the Securing-Debian-Manual). So please, excuse me if you feel this is off-topic. The problem is, how can an admin restrict remote access from a given user (through telnet and/or sshd) in order to limit his moves inside the operating system. Chrooting the daemon is a possibility, but it's not tailored in a per-user basis but globally to all users (besides you need all the tools that users might want to use in the jail). I'm looking more into a jailed enviroment like proftpd's when you sed DefaultRoot ~ (jails the user into his home directory but he's able to use all commands, without having to setup all the libraries in it). AFAIK, pam only allows to limit some user accesses (cores, memory limits..) not users movement in the OS Ideas? Regards Javi -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] This email with any attachments is confidential and may be subject to legal privilege. If it is not intended for you please reply immediately, destroy it and do not copy, disclose or use it in any way. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [off-topic?] Chrooting ssh/telnet users?
It seems pam_chroot is available at http://www.kernel.org/pub/linux/libs/pam/pre/modules/ I will try and take a look at it... Javi -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [off-topic?] Chrooting ssh/telnet users?
argh, this sounds like the sort of thing that would've been useful when i set up rsync on our company backup machine (as opposed to writing a small shell that chrooted and ran rsync). it doesn't appear to be in debian unstable; apt-cache shows no third party module for it, and it's most definitely not included in stock pam. according to the rpm changelog, redhat added it on 10/02/00, somewhere before 0.73 was merged. the readme in the modules/chroot directory identifies the source as ftp://ferret.lmh.ox.ac.uk/users/weejock/pam_chroot/. i would love to see it packaged; i put redhat's source tarball at http://etc.mp3revolution.net/pam-redhat-0.74-22.tar.gz On Fri, Oct 26, 2001 at 05:25:28PM +0200, Christian Kurz wrote: On 26/10/01, Javier Fern?ndez-Sanguino Pe?a wrote: The problem is, how can an admin restrict remote access from a given user (through telnet and/or sshd) in order to limit his moves inside the operating system. [...] AFAIK, pam only allows to limit some user accesses (cores, memory limits..) not users movement in the OS That's a wrong assumption. At least RedHat contains a pam_chroot.so module which can be used in connection with the latest ssh to limit a user into a chroot. I'm just wondering if that module is packaged already for debian or not. Christian -- Debian Developer (http://www.debian.org) 1024/26CC7853 31E6 A8CA 68FC 284F 7D16 63EC A9E6 67FF 26CC 7853 -- I think a lot of the basis of the open source movement comes from procrastinating students... -- Andrew Tridgell http://www.linux-mag.com/2001-07/tridgell_04.html
Re: [off-topic?] Chrooting ssh/telnet users?
On Fri, Oct 26, 2001 at 04:35:14PM +0100, Tim Haynes wrote:
Rishi L Khan [EMAIL PROTECTED] writes:
I think the only way to accomplish a chroot IS to include all the files
in the jail that the user needs.
[snip]
Yes. Somehow, if you're going to run something, it needs to be in the jail.
Various alternatives to consider for various reasons : busybox, rbash,
sash.
What would be nice would be a union-mount, so you could graft a real /bin
on top of /home/foo/bin, and so on. I'm not sure that `mount --bind' is the
same thing?
Umm... couldn't you have a restricted environment but with
commands hard-linked in it to the proper ones and restricting thoroughly
the hard links? (only rX, no w bits) The problem is how to do this
automatically (and not checking dynamic dependencies one by one...)
FWIW I had to implement a chroot-jailled login for someone recently; if
anyone's interested, my attempts at the relevant C, nicked in part from the
appropriate manpages, are to be found below.
There is sufficient jiggery-pokery with arg{c,v} in here to allow
ssh [EMAIL PROTECTED] cat foofile localfoofile
to transfer a file, but not to make scp work. (Don't ask me; don't take
this code as professional, bug-free, exploit-free or generally anything
other than rubbish, but it compiles, and it works.)
Will take a look...
Regards
Javi
Re: [off-topic?] Chrooting ssh/telnet users?
On Sat, Oct 27, 2001 at 01:02:45AM +0200, Javier Fernández-Sanguino Peña wrote: Umm... couldn't you have a restricted environment but with commands hard-linked in it to the proper ones and restricting thoroughly the hard links? (only rX, no w bits) The problem is how to do this automatically (and not checking dynamic dependencies one by one...) not if your luser's home directories are on a different partition from / and /usr like they should be. hard links can't have different permissions from the `originals' either btw, since with hard links neither is the `real' file; they both are. -- Ethan Benson http://www.alaska.net/~erbenson/ pgpCr3HQUkF0p.pgp Description: PGP signature
Re: [off-topic?] Chrooting ssh/telnet users?
Sunny Dubey [EMAIL PROTECTED] writes: The problem is, how can an admin restrict remote access from a given user (through telnet and/or sshd) in order to limit his moves inside the operating system. no idea if this will help but you could change their shells from bash to rbash (or bash -r) its pretty crappy however rbash seems to go out of its way to make life hard for someone - no ability to execute `cd' or `alias' at all, that sort of thing. It's not a lot of use if you want a complete chroot()ed environment with ability to do whatever they like within it; it's normally more useful to be able to organize your files into directories which rbash doesn't exactly help with. ~Tim -- The light of the world keeps shining, |[EMAIL PROTECTED] Bright in the primal glow |http://spodzone.org.uk/
Re: [off-topic?] Chrooting ssh/telnet users?
well give credit to it to Vasil Kolev
/home/image.root is an image of what you want your users to have.
Ivan Dimitrov
System Administrator
Bastun Networks
On Sat, 27 Oct 2001, Javier [iso-8859-1] Fern?ndez-Sanguino Pe?a wrote:
I would be interested only in the chroot patch. Is there any
reason you have not contributed it to openssh? Do you want me to do it?
Best regards
Javi
On Fri, Oct 26, 2001 at 05:24:13PM +0300, Ivan Dimitrov wrote:
recently i've worked on a small patch for openssh that chroots a user when
he logs in. it uses mysql for password auth. it is not posted anyware but
if you want it, send me a personal mail.
Ivan Dimitrov
System Administrator
Bastun Networks
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
--- orig-session.h Thu Oct 11 17:57:08 2001
+++ session.h Thu Oct 11 15:41:11 2001
@@ -32,5 +32,6 @@
void session_input_channel_req(int id, void *arg);
void session_close_by_pid(pid_t pid, int status);
void session_close_by_channel(int id, void *arg);
+#define AM_CHROOT
#endif
--- orig-session.c Thu Oct 11 17:53:53 2001
+++ session.c Fri Oct 12 15:38:24 2001
@@ -93,6 +93,12 @@
# include uinfo.h
#endif
+
+#ifdef AM_CHROOT
+#include sys/file.h
+#endif
+
+
/* types */
#define TTYSZ 64
@@ -162,6 +168,71 @@
static login_cap_t *lc;
#endif
+
+
+#ifdef AM_CHROOT
+/*
+ system() by W.Richard Stevens
+ */
+
+
+int
+system(const char *cmdstring) /* with appropriate signal handling */
+{
+ pid_t pid;
+ int status;
+ struct sigactionignore, saveintr, savequit;
+ sigset_tchldmask, savemask;
+
+ if (cmdstring == NULL)
+ return(1); /* always a command processor with Unix
*/
+
+ ignore.sa_handler = SIG_IGN;/* ignore SIGINT and SIGQUIT */
+ sigemptyset(ignore.sa_mask);
+ ignore.sa_flags = 0;
+ if (sigaction(SIGINT, ignore, saveintr) 0)
+ return(-1);
+ if (sigaction(SIGQUIT, ignore, savequit) 0)
+ return(-1);
+
+ sigemptyset(chldmask); /* now block SIGCHLD */
+ sigaddset(chldmask, SIGCHLD);
+ if (sigprocmask(SIG_BLOCK, chldmask, savemask) 0)
+ return(-1);
+
+ if ( (pid = fork()) 0) {
+ status = -1;/* probably out of processes */
+
+ } else if (pid == 0) { /* child */
+ /* restore previous signal actions reset signal mask
*/
+ sigaction(SIGINT, saveintr, NULL);
+ sigaction(SIGQUIT, savequit, NULL);
+ sigprocmask(SIG_SETMASK, savemask, NULL);
+
+ execl(/bin/sh, sh, -c, cmdstring, (char *) 0);
+ _exit(127); /* exec error */
+ } else {/* parent */
+ while (waitpid(pid, status, 0) 0)
+ if (errno != EINTR) {
+ status = -1; /* error other than EINTR from
waitpid() */
+ break;
+ }
+ }
+
+ /* restore previous signal actions reset signal mask */
+ if (sigaction(SIGINT, saveintr, NULL) 0)
+ return(-1);
+ if (sigaction(SIGQUIT, savequit, NULL) 0)
+ return(-1);
+ if (sigprocmask(SIG_SETMASK, savemask, NULL) 0)
+ return(-1);
+
+ return(status);
+}
+
+#endif
+
+
void
do_authenticated(Authctxt *authctxt)
{
@@ -1049,6 +1120,12 @@
#endif /* WITH_IRIX_ARRAY */
#endif /* WITH_IRIX_JOBS */
+#ifdef AM_CHROOT
+ char *mounting,*buff;
+int fd0,n,num;
+#endif
+
+
/* remove hostkey from the child's memory */
destroy_sensitive_data();
@@ -1127,6 +1204,79 @@
*/
do_pam_setcred(0);
# endif /* USE_PAM */
+# ifdef AM_CHROOT
+ if (pw-pw_gid == 888)
+ {
+ mounting=(char *) malloc(1024);
+
snprintf(mounting,1024,/var/run/sshd/%s.mount,pw-pw_name);
+ fd0=open(mounting,O_RDWR|O_CREAT|O_EXCL,S_IRUSR
|S_IWUSR);
+ if ( chdir(/home/sessions)!=0)
+ {
+ perror(Chdir to session dir failed);
+ exit(1);
+ }
+ if(fd0 != -1 )
+ {
+ flock(fd0,LOCK_EX);
+write(fd0,1,1);
+flock(fd0,LOCK_UN);
+
RE: [off-topic?] Chrooting ssh/telnet users?
There is a chroot patch for the potato openssh-1.2.3 source in /contrib however it appears to be broken. I have created a modified diff for the Debian package source which will apply the patch correctly and build an ssh_1.2.3chroot1-9.3 package. Email me if you would like the diff. As has been well covered in this thread you will need to create a chroot jail which has all the executables your chroot user requires as well as the libraries the executables rely on. There are many ways to acheive this. For a very small chrooted environment (i.e. bash, cp, scp, ls, mv etc.) I generally create this manually by copying the executables into the new structure then running ldd on them to identify the libraries. For a larger chroot environment you may want to look at dbootstrap. You will have to manually maintain your chroot (upgrading executables/security updates) unless you install APT into the chroot. I generally don't. Regards, -- Andrew J. Stephen Phone +64 4 496 4484 Team Leader, Network Operations Mobile +64 25 582 304 New Zealand PostFax+64 4 496 4914 The important thing about standards is to have them. -- Bruce Schneier, creator of the Twofish algorithm -Original Message- From: Javier Fernández-Sanguino Peña [mailto:[EMAIL PROTECTED] Sent: Saturday, 27 October 2001 02:15 To: debian-security@lists.debian.org Subject: [off-topic?] Chrooting ssh/telnet users? I have been asked for this and I was trying to figure out how to do it (would document it later on in the Securing-Debian-Manual). So please, excuse me if you feel this is off-topic. The problem is, how can an admin restrict remote access from a given user (through telnet and/or sshd) in order to limit his moves inside the operating system. Chrooting the daemon is a possibility, but it's not tailored in a per-user basis but globally to all users (besides you need all the tools that users might want to use in the jail). I'm looking more into a jailed enviroment like proftpd's when you sed DefaultRoot ~ (jails the user into his home directory but he's able to use all commands, without having to setup all the libraries in it). AFAIK, pam only allows to limit some user accesses (cores, memory limits..) not users movement in the OS Ideas? Regards Javi -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] This email with any attachments is confidential and may be subject to legal privilege. If it is not intended for you please reply immediately, destroy it and do not copy, disclose or use it in any way.
Re: [off-topic?] Chrooting ssh/telnet users?
It seems pam_chroot is available at http://www.kernel.org/pub/linux/libs/pam/pre/modules/ I will try and take a look at it... Javi
Re: [off-topic?] Chrooting ssh/telnet users?
On Fri, Oct 26, 2001 at 05:25:28PM +0200, Christian Kurz wrote: That's a wrong assumption. At least RedHat contains a pam_chroot.so module which can be used in connection with the latest ssh to limit a user into a chroot. I'm just wondering if that module is packaged already for debian or not. That seems like an interesting solution (another reader suggested it to me off the list). I will take a look and package it into Debian if it seems interesting. Javi -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [off-topic?] Chrooting ssh/telnet users?
On Friday 26 October 2001 09:14 am, Javier Fernández-Sanguino Peña wrote: I have been asked for this and I was trying to figure out how to do it (would document it later on in the Securing-Debian-Manual). So please, excuse me if you feel this is off-topic. The problem is, how can an admin restrict remote access from a given user (through telnet and/or sshd) in order to limit his moves inside the operating system. no idea if this will help but you could change their shells from bash to rbash (or bash -r) its pretty crappy however Sunny Dubey -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [off-topic?] Chrooting ssh/telnet users?
I would be interested only in the chroot patch. Is there any reason you have not contributed it to openssh? Do you want me to do it? Best regards Javi On Fri, Oct 26, 2001 at 05:24:13PM +0300, Ivan Dimitrov wrote: recently i've worked on a small patch for openssh that chroots a user when he logs in. it uses mysql for password auth. it is not posted anyware but if you want it, send me a personal mail. Ivan Dimitrov System Administrator Bastun Networks -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [off-topic?] Chrooting ssh/telnet users?
On Fri, Oct 26, 2001 at 04:35:14PM +0100, Tim Haynes wrote: Rishi L Khan [EMAIL PROTECTED] writes: I think the only way to accomplish a chroot IS to include all the files in the jail that the user needs. [snip] Yes. Somehow, if you're going to run something, it needs to be in the jail. Various alternatives to consider for various reasons : busybox, rbash, sash. What would be nice would be a union-mount, so you could graft a real /bin on top of /home/foo/bin, and so on. I'm not sure that `mount --bind' is the same thing? mount --bind would work, but you must ask yourself why you bother with chroot if your just going to bind mount the entire filesystem into the chroot jail anyway (which is just about what you must do for things to work properly) when you bind mount /bin and /usr/bin you get all the suids in those directories in the chroot, you also need /etc for the global config files many programs use. -- Ethan Benson http://www.alaska.net/~erbenson/ PGP signature
Re: [off-topic?] Chrooting ssh/telnet users?
Javier Fernández-Sanguino Peña [EMAIL PROTECTED] writes:
Yes. Somehow, if you're going to run something, it needs to be in the
jail. Various alternatives to consider for various reasons : busybox,
rbash, sash.
What would be nice would be a union-mount, so you could graft a real
/bin on top of /home/foo/bin, and so on. I'm not sure that `mount
--bind' is the same thing?
Umm... couldn't you have a restricted environment but with commands
hard-linked in it to the proper ones and restricting thoroughly the hard
links? (only rX, no w bits)
Links created this way will not work
a) cross-filesystem (and having a separate mountpoint for all chroot stuff
is regarded as basically sensible)
b) to serve to separate permissions in one link from those in the other.
The problem is how to do this automatically (and not checking dynamic
dependencies one by one...)
...and the other rule is, don't do anything automatically that could lead
to shooting yourself in the head. You are expected to sit there sweat it
out, `/bin/ls? Nh, don't need that' for each file in the jail.
FWIW I had to implement a chroot-jailled login for someone recently; if
anyone's interested, my attempts at the relevant C, nicked in part from
the appropriate manpages, are to be found below.
There is sufficient jiggery-pokery with arg{c,v} in here to allow
ssh restricteduser@box cat foofile localfoofile
to transfer a file, but not to make scp work. (Don't ask me; don't take
this code as professional, bug-free, exploit-free or generally anything
other than rubbish, but it compiles, and it works.)
Will take a look...
Bear in mind that what I did in order to set this up was a very simple
zsh# cp -av /^(mnt|proc) /mnt/chroot
zsh# chroot /mnt/chroot bash
bash# dpkg --get-selections | awk '/install$/ {print $1}' deb_list
bash# vi deb_list
bash# apt-get remove $(cat deb_list)
ie it's a complete copy of the running machine, offset by the magic of
chroot into another subdirectory (on a separate filesystem), with
significant numbers of packages removed, and various things like /bin/mount
removed.
It does *not* cater for vast hordes of users all having their own
environment, nor does it do the job properly by flinging files into the
chroot jail until they work - removing packages is not the same as building
up from minimum. But this was adequate for the user I had in mind, anyway.
~Tim
--
The light of the world keeps shining, |[EMAIL PROTECTED]
Bright in the primal glow |http://spodzone.org.uk/
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [off-topic?] Chrooting ssh/telnet users?
argh, this sounds like the sort of thing that would've been useful when i set up rsync on our company backup machine (as opposed to writing a small shell that chrooted and ran rsync). it doesn't appear to be in debian unstable; apt-cache shows no third party module for it, and it's most definitely not included in stock pam. according to the rpm changelog, redhat added it on 10/02/00, somewhere before 0.73 was merged. the readme in the modules/chroot directory identifies the source as ftp://ferret.lmh.ox.ac.uk/users/weejock/pam_chroot/. i would love to see it packaged; i put redhat's source tarball at http://etc.mp3revolution.net/pam-redhat-0.74-22.tar.gz On Fri, Oct 26, 2001 at 05:25:28PM +0200, Christian Kurz wrote: On 26/10/01, Javier Fern?ndez-Sanguino Pe?a wrote: The problem is, how can an admin restrict remote access from a given user (through telnet and/or sshd) in order to limit his moves inside the operating system. [...] AFAIK, pam only allows to limit some user accesses (cores, memory limits..) not users movement in the OS That's a wrong assumption. At least RedHat contains a pam_chroot.so module which can be used in connection with the latest ssh to limit a user into a chroot. I'm just wondering if that module is packaged already for debian or not. Christian -- Debian Developer (http://www.debian.org) 1024/26CC7853 31E6 A8CA 68FC 284F 7D16 63EC A9E6 67FF 26CC 7853 -- I think a lot of the basis of the open source movement comes from procrastinating students... -- Andrew Tridgell http://www.linux-mag.com/2001-07/tridgell_04.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [off-topic?] Chrooting ssh/telnet users?
On Fri, Oct 26, 2001 at 04:35:14PM +0100, Tim Haynes wrote:
Rishi L Khan [EMAIL PROTECTED] writes:
I think the only way to accomplish a chroot IS to include all the files
in the jail that the user needs.
[snip]
Yes. Somehow, if you're going to run something, it needs to be in the jail.
Various alternatives to consider for various reasons : busybox, rbash,
sash.
What would be nice would be a union-mount, so you could graft a real /bin
on top of /home/foo/bin, and so on. I'm not sure that `mount --bind' is the
same thing?
Umm... couldn't you have a restricted environment but with
commands hard-linked in it to the proper ones and restricting thoroughly
the hard links? (only rX, no w bits) The problem is how to do this
automatically (and not checking dynamic dependencies one by one...)
FWIW I had to implement a chroot-jailled login for someone recently; if
anyone's interested, my attempts at the relevant C, nicked in part from the
appropriate manpages, are to be found below.
There is sufficient jiggery-pokery with arg{c,v} in here to allow
ssh restricteduser@box cat foofile localfoofile
to transfer a file, but not to make scp work. (Don't ask me; don't take
this code as professional, bug-free, exploit-free or generally anything
other than rubbish, but it compiles, and it works.)
Will take a look...
Regards
Javi
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [off-topic?] Chrooting ssh/telnet users?
On Fri, Oct 26, 2001 at 05:25:28PM +0200, Christian Kurz wrote: That's a wrong assumption. At least RedHat contains a pam_chroot.so module which can be used in connection with the latest ssh to limit a user into a chroot. I'm just wondering if that module is packaged already for debian or not. That seems like an interesting solution (another reader suggested it to me off the list). I will take a look and package it into Debian if it seems interesting. Javi
Re: [off-topic?] Chrooting ssh/telnet users?
On Friday 26 October 2001 09:14 am, Javier Fernández-Sanguino Peña wrote: I have been asked for this and I was trying to figure out how to do it (would document it later on in the Securing-Debian-Manual). So please, excuse me if you feel this is off-topic. The problem is, how can an admin restrict remote access from a given user (through telnet and/or sshd) in order to limit his moves inside the operating system. no idea if this will help but you could change their shells from bash to rbash (or bash -r) its pretty crappy however Sunny Dubey
Re: [off-topic?] Chrooting ssh/telnet users?
I would be interested only in the chroot patch. Is there any reason you have not contributed it to openssh? Do you want me to do it? Best regards Javi On Fri, Oct 26, 2001 at 05:24:13PM +0300, Ivan Dimitrov wrote: recently i've worked on a small patch for openssh that chroots a user when he logs in. it uses mysql for password auth. it is not posted anyware but if you want it, send me a personal mail. Ivan Dimitrov System Administrator Bastun Networks
Re: [off-topic?] Chrooting ssh/telnet users?
On Fri, Oct 26, 2001 at 04:35:14PM +0100, Tim Haynes wrote: Rishi L Khan [EMAIL PROTECTED] writes: I think the only way to accomplish a chroot IS to include all the files in the jail that the user needs. [snip] Yes. Somehow, if you're going to run something, it needs to be in the jail. Various alternatives to consider for various reasons : busybox, rbash, sash. What would be nice would be a union-mount, so you could graft a real /bin on top of /home/foo/bin, and so on. I'm not sure that `mount --bind' is the same thing? mount --bind would work, but you must ask yourself why you bother with chroot if your just going to bind mount the entire filesystem into the chroot jail anyway (which is just about what you must do for things to work properly) when you bind mount /bin and /usr/bin you get all the suids in those directories in the chroot, you also need /etc for the global config files many programs use. -- Ethan Benson http://www.alaska.net/~erbenson/ pgpdzIHVkJvzK.pgp Description: PGP signature
Re: [off-topic?] Chrooting ssh/telnet users?
Javier Fernández-Sanguino Peña [EMAIL PROTECTED] writes:
Yes. Somehow, if you're going to run something, it needs to be in the
jail. Various alternatives to consider for various reasons : busybox,
rbash, sash.
What would be nice would be a union-mount, so you could graft a real
/bin on top of /home/foo/bin, and so on. I'm not sure that `mount
--bind' is the same thing?
Umm... couldn't you have a restricted environment but with commands
hard-linked in it to the proper ones and restricting thoroughly the hard
links? (only rX, no w bits)
Links created this way will not work
a) cross-filesystem (and having a separate mountpoint for all chroot stuff
is regarded as basically sensible)
b) to serve to separate permissions in one link from those in the other.
The problem is how to do this automatically (and not checking dynamic
dependencies one by one...)
...and the other rule is, don't do anything automatically that could lead
to shooting yourself in the head. You are expected to sit there sweat it
out, `/bin/ls? Nh, don't need that' for each file in the jail.
FWIW I had to implement a chroot-jailled login for someone recently; if
anyone's interested, my attempts at the relevant C, nicked in part from
the appropriate manpages, are to be found below.
There is sufficient jiggery-pokery with arg{c,v} in here to allow
ssh [EMAIL PROTECTED] cat foofile localfoofile
to transfer a file, but not to make scp work. (Don't ask me; don't take
this code as professional, bug-free, exploit-free or generally anything
other than rubbish, but it compiles, and it works.)
Will take a look...
Bear in mind that what I did in order to set this up was a very simple
zsh# cp -av /^(mnt|proc) /mnt/chroot
zsh# chroot /mnt/chroot bash
bash# dpkg --get-selections | awk '/install$/ {print $1}' deb_list
bash# vi deb_list
bash# apt-get remove $(cat deb_list)
ie it's a complete copy of the running machine, offset by the magic of
chroot into another subdirectory (on a separate filesystem), with
significant numbers of packages removed, and various things like /bin/mount
removed.
It does *not* cater for vast hordes of users all having their own
environment, nor does it do the job properly by flinging files into the
chroot jail until they work - removing packages is not the same as building
up from minimum. But this was adequate for the user I had in mind, anyway.
~Tim
--
The light of the world keeps shining, |[EMAIL PROTECTED]
Bright in the primal glow |http://spodzone.org.uk/
Re: [off-topic?] Chrooting ssh/telnet users?
Set the shell for the user in /etc/passwd to a script that chroots and then spawns a shell. -rishi On Fri, 26 Oct 2001, Javier [iso-8859-1] Fernández-Sanguino Peña wrote: I have been asked for this and I was trying to figure out how to do it (would document it later on in the Securing-Debian-Manual). So please, excuse me if you feel this is off-topic. The problem is, how can an admin restrict remote access from a given user (through telnet and/or sshd) in order to limit his moves inside the operating system. Chrooting the daemon is a possibility, but it's not tailored in a per-user basis but globally to all users (besides you need all the tools that users might want to use in the jail). I'm looking more into a jailed enviroment like proftpd's when you sed DefaultRoot ~ (jails the user into his home directory but he's able to use all commands, without having to setup all the libraries in it). AFAIK, pam only allows to limit some user accesses (cores, memory limits..) not users movement in the OS Ideas? Regards Javi -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [off-topic?] Chrooting ssh/telnet users?
recently i've worked on a small patch for openssh that chroots a user when he logs in. it uses mysql for password auth. it is not posted anyware but if you want it, send me a personal mail. Ivan Dimitrov System Administrator Bastun Networks On Fri, 26 Oct 2001, Javier [iso-8859-1] Fernández-Sanguino Peña wrote: I have been asked for this and I was trying to figure out how to do it (would document it later on in the Securing-Debian-Manual). So please, excuse me if you feel this is off-topic. The problem is, how can an admin restrict remote access from a given user (through telnet and/or sshd) in order to limit his moves inside the operating system. Chrooting the daemon is a possibility, but it's not tailored in a per-user basis but globally to all users (besides you need all the tools that users might want to use in the jail). I'm looking more into a jailed enviroment like proftpd's when you sed DefaultRoot ~ (jails the user into his home directory but he's able to use all commands, without having to setup all the libraries in it). AFAIK, pam only allows to limit some user accesses (cores, memory limits..) not users movement in the OS Ideas? Regards Javi -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [off-topic?] Chrooting ssh/telnet users?
On Fri, 2001-10-26 at 15:51, Rishi L Khan wrote: Set the shell for the user in /etc/passwd to a script that chroots and then spawns a shell. -rishi Hmmm, That wouldn't work as intended - since the jailed environment would have to contain all files/libraries the user needs to get his work done. On Fri, 26 Oct 2001, Javier [iso-8859-1] Fernández-Sanguino Peña wrote: Chrooting the daemon is a possibility, but it's not tailored in a per-user basis but globally to all users (besides you need all the tools that users might want to use in the jail). I'm looking more into a jailed enviroment like proftpd's when you sed DefaultRoot ~ (jails the user into his home directory but he's able to use all commands, without having to setup all the libraries in it). Unfortunately, I can't see how this should be done. The reason it works with proftpd is because it has those common commands builtin and does not depend on the files being in the jail. However, how would you use ls which resides in /bin/ls, if you are jailed into /home/username ?? As I see it, it cannot be done (though it would be nice) -- Paul Fleischer -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [off-topic?] Chrooting ssh/telnet users?
On Fri, 26 Oct 2001, Rishi L Khan wrote: Set the shell for the user in /etc/passwd to a script that chroots and then spawns a shell. That is very difficult to do. Chroot can only be run by root. On Fri, 26 Oct 2001, Javier [iso-8859-1] Fernández-Sanguino Peña wrote: I have been asked for this and I was trying to figure out how to do it (would document it later on in the Securing-Debian-Manual). So please, excuse me if you feel this is off-topic. The problem is, how can an admin restrict remote access from a given user (through telnet and/or sshd) in order to limit his moves inside the operating system. Chrooting the daemon is a possibility, but it's not tailored in a per-user basis but globally to all users (besides you need all the tools that users might want to use in the jail). I'm looking more into a jailed enviroment like proftpd's when you sed DefaultRoot ~ (jails the user into his home directory but he's able to use all commands, without having to setup all the libraries in it). AFAIK, pam only allows to limit some user accesses (cores, memory limits..) not users movement in the OS -- Tot ziens, Bart-Jan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [off-topic?] Chrooting ssh/telnet users?
I think the only way to accomplish a chroot IS to include all the files in the jail that the user needs. -rishi On 26 Oct 2001, Paul Fleischer wrote: On Fri, 2001-10-26 at 15:51, Rishi L Khan wrote: Set the shell for the user in /etc/passwd to a script that chroots and then spawns a shell. -rishi Hmmm, That wouldn't work as intended - since the jailed environment would have to contain all files/libraries the user needs to get his work done. On Fri, 26 Oct 2001, Javier [iso-8859-1] Fernández-Sanguino Peña wrote: Chrooting the daemon is a possibility, but it's not tailored in a per-user basis but globally to all users (besides you need all the tools that users might want to use in the jail). I'm looking more into a jailed enviroment like proftpd's when you sed DefaultRoot ~ (jails the user into his home directory but he's able to use all commands, without having to setup all the libraries in it). Unfortunately, I can't see how this should be done. The reason it works with proftpd is because it has those common commands builtin and does not depend on the files being in the jail. However, how would you use ls which resides in /bin/ls, if you are jailed into /home/username ?? As I see it, it cannot be done (though it would be nice) -- Paul Fleischer -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [off-topic?] Chrooting ssh/telnet users?
Rishi L Khan [EMAIL PROTECTED] writes:
I think the only way to accomplish a chroot IS to include all the files
in the jail that the user needs.
[snip]
Yes. Somehow, if you're going to run something, it needs to be in the jail.
Various alternatives to consider for various reasons : busybox, rbash,
sash.
What would be nice would be a union-mount, so you could graft a real /bin
on top of /home/foo/bin, and so on. I'm not sure that `mount --bind' is the
same thing?
FWIW I had to implement a chroot-jailled login for someone recently; if
anyone's interested, my attempts at the relevant C, nicked in part from the
appropriate manpages, are to be found below.
There is sufficient jiggery-pokery with arg{c,v} in here to allow
ssh restricteduser@box cat foofile localfoofile
to transfer a file, but not to make scp work. (Don't ask me; don't take
this code as professional, bug-free, exploit-free or generally anything
other than rubbish, but it compiles, and it works.)
~Tim
--
no se encuentra el sistema operativo|[EMAIL PROTECTED]
(seen mid-windows 98 installation) |http://spodzone.org.uk/
#include stdio.h
#include stdlib.h
#include unistd.h
#include errno.h
#include malloc.h
#include string.h
#define NOBODY (1999)
#define ROOTPATH /where/ever/
#define environ NULL
int my_system (const char *command) {
int pid, status;
if (!command)
return 1;
pid = fork();
if (pid == -1)
return -1;
if (!pid) {
char *argv[4];
argv[0] = sh;
argv[1] = -c;
argv[2] = command;
argv[3] = 0;
execve(/bin/sh, argv, environ);
exit(127);
}
do {
if (waitpid(pid, status, 0) == -1) {
if (errno != EINTR)
return -1;
} else
return status;
} while(1);
}
int main (int argc, char *argv[])
{
int r=0, t=0, i=0;
char *cmd;
r=chroot(ROOTPATH);
#if 0
if(r)
fprintf(stderr, Chroot error: %d, %d, [%s]\n\n, r, errno,
sys_errlist[errno]);
#endif
chdir(/home/someplace);
setuid(NOBODY);
setgid(NOBODY);
seteuid(NOBODY);
setegid(NOBODY);
#if 0
fprintf(stderr, Changed id: U%d G%d EU%d EG%d\n, getuid(), getgid(),
geteuid(), getegid());
#endif
for(i=t=1; iargc; i++)
t+=strlen(argv[i]);
#if 0
printf(Combined total: %d\n, t);
#endif
cmd=malloc(t+128);
strcpy(cmd, /bin/bash );
if(argc1)
strcat(cmd, -c );
for(i=t=1; iargc; i++) {
strcat(cmd, argv[i]);
strcat(cmd, );
}
#if 0
printf(Built string [%s]\n, cmd);
#endif
my_system(cmd);
return 0;
}
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [off-topic?] Chrooting ssh/telnet users?
On 26/10/01, Javier Fernández-Sanguino Peña wrote: The problem is, how can an admin restrict remote access from a given user (through telnet and/or sshd) in order to limit his moves inside the operating system. [...] AFAIK, pam only allows to limit some user accesses (cores, memory limits..) not users movement in the OS That's a wrong assumption. At least RedHat contains a pam_chroot.so module which can be used in connection with the latest ssh to limit a user into a chroot. I'm just wondering if that module is packaged already for debian or not. Christian -- Debian Developer (http://www.debian.org) 1024/26CC7853 31E6 A8CA 68FC 284F 7D16 63EC A9E6 67FF 26CC 7853 PGP signature
Re: [off-topic?] Chrooting ssh/telnet users?
Set the shell for the user in /etc/passwd to a script that chroots and then spawns a shell. -rishi On Fri, 26 Oct 2001, Javier [iso-8859-1] Fern?ndez-Sanguino Pe?a wrote: I have been asked for this and I was trying to figure out how to do it (would document it later on in the Securing-Debian-Manual). So please, excuse me if you feel this is off-topic. The problem is, how can an admin restrict remote access from a given user (through telnet and/or sshd) in order to limit his moves inside the operating system. Chrooting the daemon is a possibility, but it's not tailored in a per-user basis but globally to all users (besides you need all the tools that users might want to use in the jail). I'm looking more into a jailed enviroment like proftpd's when you sed DefaultRoot ~ (jails the user into his home directory but he's able to use all commands, without having to setup all the libraries in it). AFAIK, pam only allows to limit some user accesses (cores, memory limits..) not users movement in the OS Ideas? Regards Javi -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [off-topic?] Chrooting ssh/telnet users?
recently i've worked on a small patch for openssh that chroots a user when he logs in. it uses mysql for password auth. it is not posted anyware but if you want it, send me a personal mail. Ivan Dimitrov System Administrator Bastun Networks On Fri, 26 Oct 2001, Javier [iso-8859-1] Fern?ndez-Sanguino Pe?a wrote: I have been asked for this and I was trying to figure out how to do it (would document it later on in the Securing-Debian-Manual). So please, excuse me if you feel this is off-topic. The problem is, how can an admin restrict remote access from a given user (through telnet and/or sshd) in order to limit his moves inside the operating system. Chrooting the daemon is a possibility, but it's not tailored in a per-user basis but globally to all users (besides you need all the tools that users might want to use in the jail). I'm looking more into a jailed enviroment like proftpd's when you sed DefaultRoot ~ (jails the user into his home directory but he's able to use all commands, without having to setup all the libraries in it). AFAIK, pam only allows to limit some user accesses (cores, memory limits..) not users movement in the OS Ideas? Regards Javi -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [off-topic?] Chrooting ssh/telnet users?
On Fri, 2001-10-26 at 15:51, Rishi L Khan wrote: Set the shell for the user in /etc/passwd to a script that chroots and then spawns a shell. -rishi Hmmm, That wouldn't work as intended - since the jailed environment would have to contain all files/libraries the user needs to get his work done. On Fri, 26 Oct 2001, Javier [iso-8859-1] Fernández-Sanguino Peña wrote: Chrooting the daemon is a possibility, but it's not tailored in a per-user basis but globally to all users (besides you need all the tools that users might want to use in the jail). I'm looking more into a jailed enviroment like proftpd's when you sed DefaultRoot ~ (jails the user into his home directory but he's able to use all commands, without having to setup all the libraries in it). Unfortunately, I can't see how this should be done. The reason it works with proftpd is because it has those common commands builtin and does not depend on the files being in the jail. However, how would you use ls which resides in /bin/ls, if you are jailed into /home/username ?? As I see it, it cannot be done (though it would be nice) -- Paul Fleischer
Re: [off-topic?] Chrooting ssh/telnet users?
On Fri, 26 Oct 2001, Rishi L Khan wrote: Set the shell for the user in /etc/passwd to a script that chroots and then spawns a shell. That is very difficult to do. Chroot can only be run by root. On Fri, 26 Oct 2001, Javier [iso-8859-1] Fernández-Sanguino Peña wrote: I have been asked for this and I was trying to figure out how to do it (would document it later on in the Securing-Debian-Manual). So please, excuse me if you feel this is off-topic. The problem is, how can an admin restrict remote access from a given user (through telnet and/or sshd) in order to limit his moves inside the operating system. Chrooting the daemon is a possibility, but it's not tailored in a per-user basis but globally to all users (besides you need all the tools that users might want to use in the jail). I'm looking more into a jailed enviroment like proftpd's when you sed DefaultRoot ~ (jails the user into his home directory but he's able to use all commands, without having to setup all the libraries in it). AFAIK, pam only allows to limit some user accesses (cores, memory limits..) not users movement in the OS -- Tot ziens, Bart-Jan
Re: [off-topic?] Chrooting ssh/telnet users?
I think the only way to accomplish a chroot IS to include all the files in the jail that the user needs. -rishi On 26 Oct 2001, Paul Fleischer wrote: On Fri, 2001-10-26 at 15:51, Rishi L Khan wrote: Set the shell for the user in /etc/passwd to a script that chroots and then spawns a shell. -rishi Hmmm, That wouldn't work as intended - since the jailed environment would have to contain all files/libraries the user needs to get his work done. On Fri, 26 Oct 2001, Javier [iso-8859-1] Fern?ndez-Sanguino Pe?a wrote: Chrooting the daemon is a possibility, but it's not tailored in a per-user basis but globally to all users (besides you need all the tools that users might want to use in the jail). I'm looking more into a jailed enviroment like proftpd's when you sed DefaultRoot ~ (jails the user into his home directory but he's able to use all commands, without having to setup all the libraries in it). Unfortunately, I can't see how this should be done. The reason it works with proftpd is because it has those common commands builtin and does not depend on the files being in the jail. However, how would you use ls which resides in /bin/ls, if you are jailed into /home/username ?? As I see it, it cannot be done (though it would be nice) -- Paul Fleischer -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [off-topic?] Chrooting ssh/telnet users?
Rishi L Khan [EMAIL PROTECTED] writes:
I think the only way to accomplish a chroot IS to include all the files
in the jail that the user needs.
[snip]
Yes. Somehow, if you're going to run something, it needs to be in the jail.
Various alternatives to consider for various reasons : busybox, rbash,
sash.
What would be nice would be a union-mount, so you could graft a real /bin
on top of /home/foo/bin, and so on. I'm not sure that `mount --bind' is the
same thing?
FWIW I had to implement a chroot-jailled login for someone recently; if
anyone's interested, my attempts at the relevant C, nicked in part from the
appropriate manpages, are to be found below.
There is sufficient jiggery-pokery with arg{c,v} in here to allow
ssh [EMAIL PROTECTED] cat foofile localfoofile
to transfer a file, but not to make scp work. (Don't ask me; don't take
this code as professional, bug-free, exploit-free or generally anything
other than rubbish, but it compiles, and it works.)
~Tim
--
no se encuentra el sistema operativo|[EMAIL PROTECTED]
(seen mid-windows 98 installation) |http://spodzone.org.uk/
#include stdio.h
#include stdlib.h
#include unistd.h
#include errno.h
#include malloc.h
#include string.h
#define NOBODY (1999)
#define ROOTPATH /where/ever/
#define environ NULL
int my_system (const char *command) {
int pid, status;
if (!command)
return 1;
pid = fork();
if (pid == -1)
return -1;
if (!pid) {
char *argv[4];
argv[0] = sh;
argv[1] = -c;
argv[2] = command;
argv[3] = 0;
execve(/bin/sh, argv, environ);
exit(127);
}
do {
if (waitpid(pid, status, 0) == -1) {
if (errno != EINTR)
return -1;
} else
return status;
} while(1);
}
int main (int argc, char *argv[])
{
int r=0, t=0, i=0;
char *cmd;
r=chroot(ROOTPATH);
#if 0
if(r)
fprintf(stderr, Chroot error: %d, %d, [%s]\n\n, r, errno,
sys_errlist[errno]);
#endif
chdir(/home/someplace);
setuid(NOBODY);
setgid(NOBODY);
seteuid(NOBODY);
setegid(NOBODY);
#if 0
fprintf(stderr, Changed id: U%d G%d EU%d EG%d\n, getuid(), getgid(),
geteuid(), getegid());
#endif
for(i=t=1; iargc; i++)
t+=strlen(argv[i]);
#if 0
printf(Combined total: %d\n, t);
#endif
cmd=malloc(t+128);
strcpy(cmd, /bin/bash );
if(argc1)
strcat(cmd, -c );
for(i=t=1; iargc; i++) {
strcat(cmd, argv[i]);
strcat(cmd, );
}
#if 0
printf(Built string [%s]\n, cmd);
#endif
my_system(cmd);
return 0;
}
Re: [off-topic?] Chrooting ssh/telnet users?
On 26/10/01, Javier Fernández-Sanguino Peña wrote: The problem is, how can an admin restrict remote access from a given user (through telnet and/or sshd) in order to limit his moves inside the operating system. [...] AFAIK, pam only allows to limit some user accesses (cores, memory limits..) not users movement in the OS That's a wrong assumption. At least RedHat contains a pam_chroot.so module which can be used in connection with the latest ssh to limit a user into a chroot. I'm just wondering if that module is packaged already for debian or not. Christian -- Debian Developer (http://www.debian.org) 1024/26CC7853 31E6 A8CA 68FC 284F 7D16 63EC A9E6 67FF 26CC 7853 pgpTy6jzAzuz3.pgp Description: PGP signature
