limiting sftp users to specific dir
Hello! I finally changed my servers from Windows to Linux (SuSE 9.1). In windows I used to have F-Secure SSH-server (student licence) and I had set it up so that I could access via SFTP all the system (I also had SSH access), but others only their own directory. And what more, the SFTP directories were defined as d:\sftp\%username%. Very clean system with no problems for the users. Bear with me as I probably do not know how to ask this in a simple way and I do not know the right terms... I'll try to explain what I would like to do (almost the same as in Windows): With SuSE I had SSH server up and running very fast. So now I have different types of users: 1) Me: local user, remote with SSH and X + SCP/SFTP (unlimited) 2) Family: local users, remote with SFTP limited to users home dir (or some empty dir under it) 3) Remote family: only remote SFTP limited to some empty dir somewhere (not necessarily under home dir) The current situation with SuSE defaults is that if I create a user and use WinSCP to access the server with that user, they can see just about every file there including other users home dirs. Not good. (I thought be default Linux was more secure...) Also, just the complexity of all the stuff that is in the users home dir would confuse many users. They just need to see one empty dir where to transfer files from and to. For those that log in locally, this dir should be under the home dir, like Documents. And the 3rd type of users should only have access to one dir that is completely empty except for their own files. First question: Can this be done? (Please don't tell me I have to go back to windows server... ) Second: how? Sorry for not being more exact in defining the problem. Hopefully you got the idea. I'm not new to computers and I'm quite happy to edit config files... except that this time I didn't find what to edit (sshd_conf doesn't seem to have options for limiting users like this). -- HG
Hugo wrote:
Hello!
I finally changed my servers from Windows to Linux (SuSE 9.1). In windows I used to have F-Secure SSH-server (student licence) and I had set it up so that I could access via SFTP all the system (I also had SSH access), but others only their own directory. And what more, the SFTP directories were defined as d:\sftp\%username%. Very clean system with no problems for the users.
Bear with me as I probably do not know how to ask this in a simple way and I do not know the right terms... I'll try to explain what I would like to do (almost the same as in Windows):
With SuSE I had SSH server up and running very fast. So now I have different types of users: 1) Me: local user, remote with SSH and X + SCP/SFTP (unlimited) 2) Family: local users, remote with SFTP limited to users home dir (or some empty dir under it) 3) Remote family: only remote SFTP limited to some empty dir somewhere (not necessarily under home dir)
The current situation with SuSE defaults is that if I create a user and use WinSCP to access the server with that user, they can see just about every file there including other users home dirs. Not good. (I thought be default Linux was more secure...) Also, just the complexity of all the stuff that is in the users home dir would confuse many users. They just need to see one empty dir where to transfer files from and to. For those that log in locally, this dir should be under the home dir, like Documents. And the 3rd type of users should only have access to one dir that is completely empty except for their own files.
First question: Can this be done? (Please don't tell me I have to go back to windows server... ) Second: how?
Sorry for not being more exact in defining the problem. Hopefully you got the idea. I'm not new to computers and I'm quite happy to edit config files... except that this time I didn't find what to edit (sshd_conf doesn't seem to have options for limiting users like this).
You probably want scponly w/chroot enabled. A type of shell that only allows sftp/scp access. chroot means that the person's home directory will become their root directory, so they can't get outside it. http://www.sublimation.org/scponly/
Hi! On Thu, 21 Oct 2004 11:30:07 -0400, suse@rio.vg <suse@rio.vg> wrote:
You probably want scponly w/chroot enabled. A type of shell that only allows sftp/scp access. chroot means that the person's home directory will become their root directory, so they can't get outside it.
Thanks. I thought chroot meant setting up a some kind of "virtual" server within another server. I didn't know users can be chrooted. Again, I'm worried about how such a shell would work when the user logs in from the console (at home)? Or do I have to set up 2 accounts for each? That would really make a mess of the file permissions...?
This looks interesting and much cleaner than the chrooted OpenSSH system (which really sounds like a bubblegum patching... is this really something that can not be done with the OpenSSH? How do corporations for example provide SCP/SFTP-file sharing to their customers? Do they use windows or do they just trust the customers to not go knocking around? Or do they all just apply these patches and hope that they can keep up with updates (as YOU probably doesn't handle this kind of stuff... ) I thought this would be the most used configuration for SCP/SFTP and I thought I was just blind to see some obvious switch somewhere... sigh. I guess Linux isn't that safe operating system after all... one really needs to know and be active (=spend lot's of time to get the basic stuff working) to get it safe. Or buy the stuff from SSH. -- HG
Hugo wrote:
Again, I'm worried about how such a shell would work when the user logs in from the console (at home)? Or do I have to set up 2 accounts for each? That would really make a mess of the file permissions...?
Well, if you trust the user to be able to log in to the console, why not trust them when then sftp in? Given console access, I can own over 90% of the systems out there in minutes. Knoppix is the ultimate skeleton key.
This looks interesting and much cleaner than the chrooted OpenSSH system (which really sounds like a bubblegum patching... is this really something that can not be done with the OpenSSH? How do corporations for example provide SCP/SFTP-file sharing to their customers? Do they use windows or do they just trust the customers to not go knocking around? Or do they all just apply these patches and hope that they can keep up with updates (as YOU probably doesn't handle this kind of stuff... ) I thought this would be the most used configuration for SCP/SFTP and I thought I was just blind to see some obvious switch somewhere... sigh.
Most hosting companies and whatnot do not have actual Unix accounts for their users. It's the best security of all: no user account, no login. We just give them FTP or access their files via an ssl website. Much more secure for all. That said, for some instances, I've used scponly to keep them in their place, but still allow secure file access. scponly is great. No worries about patching existing services.
I guess Linux isn't that safe operating system after all... one really needs to know and be active (=spend lot's of time to get the basic stuff working) to get it safe. Or buy the stuff from SSH.
Remember, just because the user can browse the filesystem through sftp, doesn't mean they can access anything they don't have permission to. Sftp doesn't give them access to anything they couldn't already access by logging in. The user sees the same access regardless of whether they login or sftp in. This isn't a flaw, but actually DESIRABLE in 99% of the cases. If you give a user an account, you are trusting that user with the public areas of that server. That means they'll be able to see most of the system files, but not write to them. That also usually means they can't view other people's home directories, and it definitely means they're not going to be seeing the inside of the file where the passwords are stored. Unlike windows, Linux is designed to be secure even to people who access the general filesystem. It also allows you to tailor your system to create directories where certain groups of people have access, but not others. Also, there is a HUGE difference in Linux in the area of read vs. write access. A normal user has read access to most things, but can only write to a very limited area. For instance, if I was a normal user on your system, I could sftp in and go to the /etc directory and see the passwd file, but I would be completely unable to upload a new one over it.
Hi! Thanks for the answer again. On Fri, 22 Oct 2004 13:58:09 -0400, suse@rio.vg <suse@rio.vg> wrote:
Hugo wrote:
Again, I'm worried about how such a shell would work when the user logs in from the console (at home)? Or do I have to set up 2 accounts for each? That would really make a mess of the file permissions...?
Well, if you trust the user to be able to log in to the console, why not trust them when then sftp in? Given console access, I can own over 90%
Because, they access the computer from a computer and environment that is not possibly secure of course. For instance, open SFTP from work place. Suddenly the the boss asks you to hand out some papers... you go look for them... ah did I close the SFTP? I heppen to be one of the guys that thing security policies are not much more than means to transfer the blame on somebody else. If there is a way to make the system secure, it should be made so... not write guidelines about it.
of the systems out there in minutes. Knoppix is the ultimate skeleton key.
To get to the console, you'd have to come to my home. To get SFTP connection, you do not. How much time would it take you to own a system with SSH/SCP/SFTP access with default SuSE 9.1 permissions? That's what I'm more conserned of.
Most hosting companies and whatnot do not have actual Unix accounts for their users. It's the best security of all: no user account, no login. We just give them FTP or access their files via an ssl website. Much more secure for all.
Well, at a company used to work for, we gave SCP/SFTP access to our clients to transfer data to us. Yes, results were given back sometimes through SSL. You suggest FTP! None of our clients would have done that!
That said, for some instances, I've used scponly to keep them in their place, but still allow secure file access. scponly is great. No worries about patching existing services.
I'm looking into it. It sure looks like the best alternative.
I guess Linux isn't that safe operating system after all... one really needs to know and be active (=spend lot's of time to get the basic stuff working) to get it safe. Or buy the stuff from SSH.
Remember, just because the user can browse the filesystem through sftp, doesn't mean they can access anything they don't have permission to. Sftp doesn't give them access to anything they couldn't already access by logging in. The user sees the same access regardless of whether they login or sftp in. This isn't a flaw, but actually DESIRABLE in 99% of the cases.
I beg to differ. I think it is desirable only for admin-type of users and geeks that want to know everything about everything. In our current organization we have one linux partition mapped directly as windows samba share. There are all the same stuff, like libs and binaries that we analysts need while working in Linux, and it really confuses the sales people for instance. They are sometimes even afraid to use it as it is packed with stuff they do not know. They would not want to see the same things there even though they have scp/sftp access to it also (and there they need all that stuff for it to work) ... but that's work, I'm trying to set this up at home and make a better job out of it - as you can tell, I'm not a sysadmin. :-)
If you give a user an account, you are trusting that user with the public areas of that server. That means they'll be able to see most of the system files, but not write to them. That also usually means they can't view other people's home directories, and it definitely means
Ah, but for instance in SuSE 9.1 default configuration they can see other users home dirs! And as I'm quite new to administrering linux, I do not know what other things they can see and should not be able to see!
they're not going to be seeing the inside of the file where the passwords are stored.
Ah, one of those things that I really do not know... as I suspect that somehow they need to be available for the initial autentication.
Unlike windows, Linux is designed to be secure even to people who access the general filesystem. It also allows you to tailor your system to create directories where certain groups of people have access, but not
This all applies to windows too. If you haven't notices. I do not want any win vs. linux here, but I must say that at least the default in windows is that the users can not view other users home dirs.
others. Also, there is a HUGE difference in Linux in the area of read vs. write access. A normal user has read access to most things, but can only write to a very limited area.
For instance, if I was a normal user on your system, I could sftp in and go to the /etc directory and see the passwd file, but I would be completely unable to upload a new one over it.
But if you can read it, you can start cracking it, right? I still fail to see why all users should even see those places? I mean that there is no switch that would restrict remote users from even seeing them. Because then that leaves me in a position that I can not open that service at all. I know that I do not know as much about linux as the possible hackers... and as default permissions might not be the most secure, I know that I will miss something and create a hole. But I'm really looking into the scponly shell. Thanks. -- HG
Quoting Hugo <hg.list@gmail.com>:
Well, if you trust the user to be able to log in to the console, why not trust them when then sftp in? Given console access, I can own over 90%
Because, they access the computer from a computer and environment that is not possibly secure of course. For instance, open SFTP from work place. Suddenly the the boss asks you to hand out some papers... you go look for them... ah did I close the SFTP?
I heppen to be one of the guys that thing security policies are not much more than means to transfer the blame on somebody else. If there is a way to make the system secure, it should be made so... not write guidelines about it.
It all depends on what you mean by "secure". Security and convenience are always a tradeoff. If you put work into it, applying the NSA patches, using vast ACL's, chroot every login, etc etc, you can make linux completely secure, but it won't be terribly usable, as every user would have to install every program and library they'd want to use into their own home directory and sharing of files would be completely out the window. With linux, it's not a question of "policy", but a matter of how much convenience you're willing to give up.
of the systems out there in minutes. Knoppix is the ultimate skeleton key.
To get to the console, you'd have to come to my home. To get SFTP connection, you do not. How much time would it take you to own a system with SSH/SCP/SFTP access with default SuSE 9.1 permissions? That's what I'm more conserned of.
Ah, but you said you gave these people access to the console, that's why I mentioned it. But honestly, I don't know of any attack vector from just simple sftp. If I had both sftp and ssh, I might be able to smuggle a rootkit onto the system and execute it via ssh. However, if you keep your system up to date with YoU or fou4s, that's rather unlikely to work. (And it will still work with a chroot'd sftp) The most malicious thing I could do from sftp is get some information out of your system like the list of users and some of the configuration files. On a default system, none of those config files will have a password in it, so it's not really all that useful to an attacker.
Remember, just because the user can browse the filesystem through sftp, doesn't mean they can access anything they don't have permission to. Sftp doesn't give them access to anything they couldn't already access by logging in. The user sees the same access regardless of whether they login or sftp in. This isn't a flaw, but actually DESIRABLE in 99% of the cases.
I beg to differ. I think it is desirable only for admin-type of users and geeks that want to know everything about everything. In our current organization we have one linux partition mapped directly as windows samba share. There are all the same stuff, like libs and binaries that we analysts need while working in Linux, and it really confuses the sales people for instance. They are sometimes even afraid to use it as it is packed with stuff they do not know. They would not want to see the same things there even though they have scp/sftp access to it also (and there they need all that stuff for it to work) ... but that's work, I'm trying to set this up at home and make a better job out of it - as you can tell, I'm not a sysadmin. :-)
Putting the whole Linux partition as a samba share is kinda silly. Most people create a directory with the proper permissions to allow everyone to access it through samba. Coupled with the Home dir functionality of samba, it makes much more sense to most windows users and keeps your filesystem tidy. But to the issue of sftp access to the whole filesystem: It's desirable so that the user can get to the shared areas of the disk. If the user can only access his home dir, how can he work on shared projects? Lastly: When the windows people sftp in, they're going to start in their home directory, not in the root area, so your worry about confusion is unfounded. It's only if they traverse up the file system that they can see the rest of it. However, with sftp, just like when you login, you start out in your home directory.
Ah, but for instance in SuSE 9.1 default configuration they can see other users home dirs! And as I'm quite new to administrering linux, I do not know what other things they can see and should not be able to see!
That's your opinion. It all depends on your environment. A `chmod 700 *` in /home will fix that up.
Ah, one of those things that I really do not know... as I suspect that somehow they need to be available for the initial autentication.
Your suspicion is incorrect. The passwords in linux are stored in /etc/shadow. Take a look at the file, you have to be root or in the shadow group to read it. In Unix, there is a thing called "setuid" that allows certain processes to increase their privelege level. The login procedure does this in order to read the password. You'll also note that the actual passwords in /etc/shadow are encrypted, adding another layer of security. Granted, if someone maliciously manages to get your /etc/shadow, they can still brute force crack it, but you'll at least have some lead time. And, if they can get the /etc/shadow, they've probably already owned your system, so it's a bit late :-)
This all applies to windows too. If you haven't notices. I do not want any win vs. linux here, but I must say that at least the default in windows is that the users can not view other users home dirs.
SuSE decided that it would allow read access, but not write access to other peoples home directories. It entirely depends on what type of environment you have.
For instance, if I was a normal user on your system, I could sftp in and go to the /etc directory and see the passwd file, but I would be completely unable to upload a new one over it.
But if you can read it, you can start cracking it, right?
No, because the passwords are not stored in /etc/passwd.
I still fail to see why all users should even see those places? I mean that there is no switch that would restrict remote users from even seeing them. Because then that leaves me in a position that I can not open that service at all. I know that I do not know as much about linux as the possible hackers... and as default permissions might not be the most secure, I know that I will miss something and create a hole.
Users need to be able to read those places because they need to be able to EXECUTE from those places. To someone from the windows world, the Linux filesystem seems hopeless complex. In windows, programs and libraries are generally in to places, individially under /Program Files/ and in the massive /WINDOWS/ area. In linux, they are layed out according to what they are. Libraries go in /lib directories, programs in /bin directories, and configuration in /etc. When I run a program, it access all of these areas, so I need to be able to read them. For instance, when I run ssh, it accesses the following libraries: libpthread.so.0 => /lib64/libpthread.so.0 libutil.so.1 => /lib64/libutil.so.1 libz.so.1 => /lib64/libz.so.1 libnsl.so.1 => /lib64/libnsl.so.1 libcrypto.so.0.9.7 => /usr/lib64/libcrypto.so.0.9.7 libcrypt.so.1 => /lib64/libcrypt.so.1 libgssapi.so.1 => /usr/lib64/libgssapi.so.1 libkrb5.so.17 => /usr/lib64/libkrb5.so.17 libcom_err.so.2 => /lib64/libcom_err.so.2 libasn1.so.6 => /usr/lib64/libasn1.so.6 libroken.so.16 => /usr/lib64/libroken.so.16 libc.so.6 => /lib64/libc.so.6 /lib64/ld-linux-x86-64.so.2 => /lib64/ld-linux-x86-64.so.2 libdl.so.2 => /lib64/libdl.so.2 libresolv.so.2 => /lib64/libresolv.so.2 libdb-4.1.so => /usr/lib64/libdb-4.1.so It also accesses the system-wide configuration files in /etc/ssh and my own ~/.ssh/ files. You'll note, however, that as a user, I have no write access to any of those files outside my home dir. A user logged into the system generally needs access to a wide array of files in order to run programs. ssh is a comparatively simple example. The list of dependencies for things like KDE and GNOME programs are enormous. It isn't as easy to create a hole as you think. Linux was largely designed with the typical hacker mentality of "security through obscurity is worthless". The user gets to read most things, but not write. The system areas of SuSE have pretty good security, especially if kept up to date. I'd recommend getting a book on Linux Systems Administraton. I'm not trying to be condescending. Linux uses a very different paradigm for security than windows. Many of the assumptions you've come to rely upon from windows do not apply to linux. A book can give you the broad idea of how Linux is set up. Forums like this list can help you with specifics, but the broader theoretical knowledge is much better obtained from a real book.
Hi! Thanks again for very enlightening answer! On Sat, 23 Oct 2004 11:31:28 -0400, suse@rio.vg <suse@rio.vg> wrote:
Quoting Hugo <hg.list@gmail.com>:
It all depends on what you mean by "secure". Security and convenience are always a tradeoff. If you put work into it, applying the NSA patches, using
What I meant was that I believe that the system should be made so secure that I do not have to worry about users making a error (which in corporate world would be regarded as doing something against the policy). In my case, this means that those who have remote access, could not even see things outside their home - or if somebody else gets hold of their session.
With linux, it's not a question of "policy", but a matter of how much convenience you're willing to give up.
I do understand what you are saying as general. In the chrooted sftp case, though, I can not see it. But I get your point.
Ah, but you said you gave these people access to the console, that's why I
Indeed, at least some of them. But the console is in "secure location" under my nose. :-)
mentioned it. But honestly, I don't know of any attack vector from just simple sftp. If I had both sftp and ssh, I might be able to smuggle a rootkit onto
I was thinking about not allowing ssh, but just sftp. I just didn't get there yet.
the system and execute it via ssh. However, if you keep your system up to date with YoU or fou4s, that's rather unlikely to work. (And it will still work
I have the automatic updates on even though it has left my system unbootable twice after kernel update.... :-( but I already know how to fix that.
The most malicious thing I could do from sftp is get some information out of your system like the list of users and some of the configuration files. On a default system, none of those config files will have a password in it, so it's not really all that useful to an attacker.
Except that my personal information stored on the computer might be compromised.
Putting the whole Linux partition as a samba share is kinda silly. Most people create a directory with the proper permissions to allow everyone to access it through samba. Coupled with the Home dir functionality of samba, it makes much more sense to most windows users and keeps your filesystem tidy.
Ah, sorry. I did confuse it a little. Not the whole partition, but a dir under that partition that I actually regard as a partition. The libs and bins there are our own products and scripts, not the ones from Linux. But still backs up my point that if users see strange dirst called lib and bin and so on, they get confused. Home dirs are also shared like you say, but all work is "group work" and stored in the shared area and not home dirs.
Lastly: When the windows people sftp in, they're going to start in their home directory, not in the root area, so your worry about confusion is unfounded.
The best and about only graphical sftp program is WinSCP. And that makes it way too easy to skip back to / and start browsing around.
It's only if they traverse up the file system that they can see the rest of it.
Like I said many times before, because I do not know enough about Linux, I'm very afraid of them seeing around. I know have a little better understanding about it - thanks to you.
Ah, but for instance in SuSE 9.1 default configuration they can see other users home dirs! And as I'm quite new to administrering linux, I do not know what other things they can see and should not be able to see!
That's your opinion. It all depends on your environment. A `chmod 700 *` in /home will fix that up.
Your suspicion is incorrect. The passwords in linux are stored in /etc/shadow. [snip] Thanks for this lengthy explanation. I knew about /etc/passwd, but I had never heard about the shadow. Now that I looked at my passwd file for the first time, I noticed that the password hashes are not stored
Well, by environment is almost default installation of SuSE 9.1. I know chmod would fix that... I was just a little more than little surprised that it is set up the way it is. Noticing that led me thinking that maybe there are lot's of other places where I should say chmod to get this box secure. Thankfully /etc/passwd and shadow doesn't seem to be such places. there like I though (but in the shadow). Thanks for the setuid explanation also. It's not the users reading those files, but root.
EXECUTE from those places. To someone from the windows world, the Linux filesystem seems hopeless complex. In windows, programs and libraries are generally in to places, individially under /Program Files/ and in the massive /WINDOWS/ area. In linux, they are layed out according to what they are. Libraries go in /lib directories, programs in /bin directories, and configuration in /etc. When I run a program, it access all of these areas, so
What actually confuses me more is that I have noticed that the dirs are not really that standard. I remember setting up Apache on this box. Installation was easy (with YAST), but everything else was ... well RTFM for long time :-) The problem was that the manuals YAST installed with it didn't point to the same directories. And as no installation program asked where to put that... took me a long time to find them! It was very confusing as the installation and manual wasn't in "sync."
It isn't as easy to create a hole as you think. Linux was largely designed with the typical hacker mentality of "security through obscurity is worthless". The user gets to read most things, but not write. The system areas of SuSE have pretty good security, especially if kept up to date.
Ok, I believe you. And I fully sign the "security through obscurity is worthless". But I'm affraid that it is insecurity through obscurity that might happen. Thinking back at the situation we had in previous (data mining) company. Customers scp data in. I do not know how that was set up. But if they could only see their own directory, the system admin would have to spend time double checking that the customers do not by accident get to see something they should not. But of course, chrooting should answer this.
I'd recommend getting a book on Linux Systems Administraton. I'm not trying to be condescending. Linux uses a very different paradigm for security than
I tried. But there are not good Linux books out there... well there are, but they are all outdated! And since all distros are quite different, I wanted to find one about SuSE. No such luck.... and so the best and most uptodate books I could find were the SuSE PDF manuals. But of course, they talk about everything and nothing so narrow as chrooting sftp.
Forums like this list can help you with specifics, but the broader theoretical knowledge is much better obtained from a real book.
I'm really sorry... I really thought there was just some small line in some config file that I had missed, and I thought I'm really asking something simple and specific. But I'm really grateful for you answers and pointers. Thanks again. -- HG
Hugo wrote:
The best and about only graphical sftp program is WinSCP. And that makes it way too easy to skip back to / and start browsing around.
I have one user that I allow to have limited access to our server, through WinSCP. I limited his access to his home directory by making his default shell rbash instead of bash (restricted bash). It worked fine for the limited access I wanted him to have remotely. When in the office he uses a Windows workstation and access is through Samba, which allows him a few extra directories. You might want to check up on rbash. It is a way to restrict remote access (ssh or scp). -- Joe Morris New Tribes Mission Email Address: Joe_Morris@ntm.org Registered Linux user 231871
Hi! On Sat, 23 Oct 2004 12:28:30 -0500, Joe Morris (NTM) <joe_morris@ntm.org> wrote:
I have one user that I allow to have limited access to our server, through WinSCP. I limited his access to his home directory by making his default shell rbash instead of bash (restricted bash). It worked
Thanks. I also got the same pointer from Wolfgang off-list. Also thanks to Petri for pointing out that the ssh server from SSH.com might actually be free for non commercial user (I'm looking at this for home usage!). I haven't checked yet, but the ssh server should be available via ftp. I think I will have to uninstall the OpenSSH and replace it completely with the SSH variant in this case. Anyhow, I now have a quite a few possibilities. I think the closesto to what I was originally looking for would be available with the SSH.com server, but the WebDAV route actually seems very interesting indeed. I think I will check that first. Thanks to all! -- HG
Am Sonntag, 24. Oktober 2004 10:10 schrieb Hugo:
On Sat, 23 Oct 2004 12:28:30 -0500, Joe Morris (NTM) <joe_morris@ntm.org> wrote:
I have one user that I allow to have limited access to our server, through WinSCP. I limited his access to his home directory by making his default shell rbash instead of bash (restricted bash). It worked
Thanks. I also got the same pointer from Wolfgang off-list. [...]
Just to put this straight: I didn't mention rbash but rssh! http://www.pizzashack.org/rssh/ http://www.pizzashack.org/rssh/faq.shtml#5 http://www.pizzashack.org/rssh/faq.shtml#12 Wolfgang
Hello! On Thu, 21 Oct 2004 18:09:23 +0300 Hugo <hg.list@gmail.com> wrote:
Hello!
I finally changed my servers from Windows to Linux (SuSE 9.1). In windows I used to have F-Secure SSH-server (student licence) and I had set it up so that I could access via SFTP all the system (I also had SSH access), but others only their own directory. And what more, the SFTP directories were defined as d:\sftp\%username%. Very clean system with no problems for the users.
Bear with me as I probably do not know how to ask this in a simple way and I do not know the right terms... I'll try to explain what I would like to do (almost the same as in Windows):
With SuSE I had SSH server up and running very fast. So now I have different types of users: 1) Me: local user, remote with SSH and X + SCP/SFTP (unlimited) 2) Family: local users, remote with SFTP limited to users home dir (or some empty dir under it) 3) Remote family: only remote SFTP limited to some empty dir somewhere(not necessarily under home dir)
The current situation with SuSE defaults is that if I create a user and use WinSCP to access the server with that user, they can see just about every file there including other users home dirs. Not good.
I think the problem stems from the fact that when you add a new user using YaST (using all default settings), the default group would be "users" and the permissions on the home directory would be something like this: drwxr-xr-x So, yes, this is *not* good since the group "other" will have read + execute permissions on one's home directory. Also, depending on your needs, putting everyone in the same group (e.g. "users") can be considered "not good" as well. And this is why "other users" can see other users' home directories.
(I thought be default Linux was more secure...)
Well, maybe this is true for the "Personal" or "Professional" versions of *SUSE* Linux ;) (Not sure about the server version since I haven't tried it.) Apparently there's a problem, IMHO, with the current implementation in YaST when adding users using the default settings. Anyway, I'm sure not all linux distros behave the same way. Besides, there's a "fix" for that default behavior of YaST -- see below.
Also, just the complexity of all the stuff that is in the users home dir would confuse many users. They just need to see one empty dir where to transfer files from and to. For those that log in locally, this dir should be under the home dir, like Documents. And the 3rd type of users should only have access to one dir that is completely empty except for their own files.
First question: Can this be done? (Please don't tell me I have to go back to windows server... ) Second: how?
Somebody already mentioned about "chrooting" or "scponly" so let me just mention a completely different approach. First, when adding users, try the "old" way, something like: 1. groupadd newgroup 2. useradd newuser -g newgroup 3. passwd newuser 4. mkdir /home/newuser 5. chown -R newuser:newgroup /home/newuser 6. chmod 700 /home/newuser Now, for the remote (secure) file transfers try this setting: Apache+SSL+WebDAV+acl One advantage here is that, most likely, they are already installed in your linux box. Just edit the conf files, setup permissions (acl), start Apache and everything's done :) Besides, if those who need to transfer files remotely are using Windows, they just need to "Add a Network Place" and no need to install additional programs.
Sorry for not being more exact in defining the problem. Hopefully you got the idea. I'm not new to computers and I'm quite happy to edit config files... except that this time I didn't find what to edit(sshd_conf doesn't seem to have options for limiting users like this).
PS. BTW, just a side note, if you're really concerned about security, perhaps you should try the server version and use SELinux. Or, check some other linux distros that are specifically made for servers. Or, try a BSD flavor of Unix, OpenBSD or NetBSD, anyone? :) But of course, even SUSE Personal can be "hardened" -- it just need a bit more work ;) -- - E - on SUSE 9.1 | blackbox 0.65 | copperwalls was here ;) "The righteous themselves will possess the earth, And they will reside forever upon it." - Psalms 37:29
Hi! Thanks for the answer. On Sun, 24 Oct 2004 01:47:43 +0900, - Edwin - <copperwa11s@yahoo.co.jp> wrote:
I think the problem stems from the fact that when you add a new user using YaST (using all default settings), the default group would be "users" and the permissions on the home directory would be something like this:
drwxr-xr-x
Yes, this is what happens.
So, yes, this is *not* good since the group "other" will have read + execute permissions on one's home directory. Also, [...]
(I thought be default Linux was more secure...)
Well, maybe this is true for the "Personal" or "Professional" versions of *SUSE* Linux ;) (Not sure about the server version since I haven't tried it.)
We do have one SuSE "server" at work, but it's actually 64bit Professional 9.0 :-)
Apparently there's a problem, IMHO, with the current implementation in YaST when adding users using the default settings. Anyway, I'm sure not all linux distros behave the same way. Besides, there's a "fix" for that default behavior of YaST -- see below.
YaST is actually the reason why I chose SuSE. I saw it at work and I thought that it is the best things I've seen in Linux for some time. It still needs lot's of work (install samba, start samba, add users... ups, no way to add users for samba :-), but it's getting there.
Somebody already mentioned about "chrooting" or "scponly" so let me just mention a completely different approach. [snip] Apache+SSL+WebDAV+acl
That is actually interesting... thanks. I'll look into that too.
Besides, if those who need to transfer files remotely are using Windows, they just need to "Add a Network Place" and no need to install additional programs.
Even more interesting! -- HG
Hi Hugo, Hugo schrieb:
Hi!
Thanks for the answer.
On Sun, 24 Oct 2004 01:47:43 +0900, - Edwin - <copperwa11s@yahoo.co.jp> wrote:
I think the problem stems from the fact that when you add a new user using YaST (using all default settings), the default group would be "users" and the permissions on the home directory would be something like this:
drwxr-xr-x
Yes, this is what happens.
and it`s why SuSE Linux is called "Nürnberg Windows".
So, yes, this is *not* good since the group "other" will have read + execute permissions on one's home directory. Also,
One need`s x-Perm to read the content`s of a Dirextory.
[...]
(I thought be default Linux was more secure...)
Linux is just the Kernel. Every other Progranm is called Aplication. And yes, the Kernel is fairly secure if configured correct. ;-)
Well, maybe this is true for the "Personal" or "Professional" versions of *SUSE* Linux ;) (Not sure about the server version since I haven't tried it.)
It`s the same in the SLES-Versions. (And I, personally don`t like this ;-(( )
We do have one SuSE "server" at work, but it's actually 64bit Professional 9.0 :-)
But _sometimes_ better default configuration.
Apparently there's a problem, IMHO, with the current implementation in YaST when adding users using the default settings. Anyway, I'm sure not all linux distros behave the same way. Besides, there's a "fix" for that default behavior of YaST -- see below.
IMHO yast is a fairly good Program, but Users are better added manually. (And if you did it twice it`s faster too.) Btw. If you want to get around the bad default permissions, you should type: vi /etc/profile /umask /022 cw077 :wq (Or in other words: edit the Umask in Systemwide profile) Dirk TRIA IT-consulting GmbH Joseph-Wild-Straße 20 81829 München Germany Tel: +49 (89) 92907-0 Fax: +49 (89) 92907-100 http://www.tria.de -------------------------------------------------------- working hard | for your success -------------------------------------------------------- Registergericht München HRB 113466 USt.-IdNr. DE 180017238 Steuer-Nr. 802/40600 Geschäftsführer: Richard Hofbauer Rosa Igl -------------------------------------------------------- Nachricht von: dirk.schreiner@tria.de Nachricht an: suse-security@suse.com # Dateianhänge: 0 Die Mitteilung dieser E-Mail ist vertraulich und nur für den oben genannten Empfänger bestimmt. Wenn Sie nicht der vorgesehene Empfänger dieser E-Mail oder mit der Aushändigung an ihn betraut sind, weisen wir darauf hin, daß jede Form der Kenntnisnahme, Veröffentlichung, Vervielfältigung sowie Weitergabe des Inhalts untersagt ist. Wir bitten Sie uns in diesem Fall umgehend zu unterrichten. Vielen Dank The information contained in this E-Mail is privileged and confidental intended only for the use of the individual or entity named above. If the reader of this message is not the intended recipient or competent to deliver it to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this E-Mail is strictly prohibited. If you have received this E-Mail in error, please notify us immediately. Thank you
participants (6)
-
- Edwin - -
Dirk Schreiner -
Hugo -
Joe Morris (NTM) -
suse＠rio.vg -
Wolfgang Franke