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.