Hi! On Thu, 21 Oct 2004 11:30:07 -0400, 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...?

http://www.sublimation.org/scponly/

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

Hi! Thanks for the answer again. On Fri, 22 Oct 2004 13:58:09 -0400, 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

Hi! Thanks again for very enlightening answer! On Sat, 23 Oct 2004 11:31:28 -0400, suse@rio.vg wrote:

Quoting Hugo :

...

...

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

Hi! On Sat, 23 Oct 2004 12:28:30 -0500, Joe Morris (NTM) 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

Hi Hugo, Hugo schrieb:

Hi!

Thanks for the answer.

On Sun, 24 Oct 2004 01:47:43 +0900, - Edwin - 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