How would I allow a user to connect to an FTP server, upload and download files and delete files as well, if that server is in enforcing mode for SELinux?
step 1) delete FTPD, and use ssh/scp/rscp instead.
errr, I meant, sftp, not rscp
Heh.. yeah. But the client isn’t gonna go for that. LOL. Any way to allow regular ol’ FTP using SELinux? Or does that just defeat the purpose of having a secure SELlinux server entirely?
Thanks Tim
Maybe use FTP in a jail? Or Linux containers?
2015-03-03 0:43 GMT+02:00 Tim Dunphy :
FTP is not safe as it does not encrypt username(s) and password(s) or traffic during transfer.
RHEL/CentOS provides SELinux booleans and settings at least for vsftpd
(very secure ftpd). Please use it, if possible.
you could also recommend filezilla to your clients, it’s available for mac, microsoft and linux and supports sftp. But I know there are still use cases for ftp.
I’d choose SSH for my own users. And for customers if proper steps are taken to prevent any interactive shells (it’s even dicier with shared hosting).
SFTP clients are now as readily available as FTP clients.
Unless you’re going to tell me it needs to be done from a box you absolutely positively cannot install any new software on, I simply don’t believe that you cannot use anything but FTP.
Not exactly, but it fights the same set of goals that SELinux was created to support.
The point of SELinux is to erect walls that prevent a lesser breach from turning into a total breach of the system’s security. Allowing FTP doesn’t prevent SELinux from working.
If FTP exposes one of your user’s passwords to the wide world, *theoretically* that means you have done nothing worse than providing unauthorized users access to that user’s account.
(Not that that isn’t bad enough.)
Unfortunately, local root-escalation exploits pop up from time to time which allow anyone with a login on that box to turn themselves into superuser, which allows them to defeat SELinux.
Incidentally, it is possible to configure SSH to allow SFTP but not interactive logins. You should also chroot SFTP users. This thread seems to have the details you need:
By doing that, even a bad user who gives away their login credentials to a bad actor isn’t opening you to a risk of a local root escalation exploit.
What is the context here? The big problem with ftp is that it passes the user credentials in the clear. There is nothing particularly wrong with an anonymous ftp download area where the files are put in place with something more secure – but it is usually easier to use http for that and you’ll have less trouble with firewalls.
Enough about FTP vs SFTP. This is exactly the kind of unhelpful discussion that I was referring to last month about the conversations on this list. CentOS is an *enterprise* distribution and as such it would be expected that people are either bound by corporate restrictions, or have some other requirements that you’re not aware of. A single helpful comment reminding someone that they should be using SFTP instead of FTP is the only appropriate thing to be saying here, not this dead-horse-beating.
It does require that you have an understanding of selinux, and are not just looking for a magic incantation to make it work. You can look at the audit log in /var/log/audit to get an idea of what is failing, and also the
‘audit2why’ and ‘audit2allow’ commands can help to suggest what selinux settings need to be changed or are getting in the way.
P.S. FTP is not secure, so you should try to use SFTP if you are able to influence the requirements.
❧ Brian Mathis
@orev
That seems like an awfully convenient rug to sweep problems under.
Can’t fix a security problem? Corporate restrictions!
Can’t require sensible security defaults restrictions by default? Corporate restrictions!
Can’t move off IE6? Corporate restrictions!
This seems like code for “We’d really rather computing in 2015 worked like computing in 1995.”
I’d say this continued “dead horse beating” is helpful. No one should come away from proposing a solution based on FTP in 2015 without being chastised for it.
Guys,
I hear all your arguments against using FTP. I completely get all that. But I am making things a little bit safer by using virtual users that have no access to the file system. The ftp user account has a shell of
/bin/false. And I was able to get proftpd working with SELinux using setsebool -P ftp_home_dir on.
The client is recalcitrant to using any technology he doesn’t know. I have tried explaining to him that SFTP would make things safer. But in the end it’s his money and his choice. He owns all the content he’s uploading, so it’s really his neck if it gets owned. But I think I’ve done a reasonable job of keeping things safe. Still open to criticism of course. And I
appreciate all your input.
15 thoughts on - Selinux Allow FTP
step 1) delete FTPD, and use ssh/scp/rscp instead.
errr, I meant, sftp, not rscp
Heh.. yeah. But the client isn’t gonna go for that. LOL. Any way to allow regular ol’ FTP using SELinux? Or does that just defeat the purpose of having a secure SELlinux server entirely?
Thanks Tim
Maybe use FTP in a jail? Or Linux containers?
2015-03-03 0:43 GMT+02:00 Tim Dunphy:
FTP is not safe as it does not encrypt username(s) and password(s) or traffic during transfer.
RHEL/CentOS provides SELinux booleans and settings at least for vsftpd
(very secure ftpd). Please use it, if possible.
Also check this out: http://www.bitvise.com/ftp-bridge
Good advice guys. I’ll check out vsftpd. Thanks!
Tim
Sent from my iPhone
you could also recommend filezilla to your clients, it’s available for mac, microsoft and linux and supports sftp. But I know there are still use cases for ftp.
I’d choose SSH for my own users. And for customers if proper steps are taken to prevent any interactive shells (it’s even dicier with shared hosting).
Use FTPS protocol?
http://wiki.vpslink.com/Configuring_vsftpd_for_secure_connections_(TLS/SSL/SFTP)
Why not?
SFTP clients are now as readily available as FTP clients.
Unless you’re going to tell me it needs to be done from a box you absolutely positively cannot install any new software on, I simply don’t believe that you cannot use anything but FTP.
Not exactly, but it fights the same set of goals that SELinux was created to support.
The point of SELinux is to erect walls that prevent a lesser breach from turning into a total breach of the system’s security. Allowing FTP doesn’t prevent SELinux from working.
If FTP exposes one of your user’s passwords to the wide world, *theoretically* that means you have done nothing worse than providing unauthorized users access to that user’s account.
(Not that that isn’t bad enough.)
Unfortunately, local root-escalation exploits pop up from time to time which allow anyone with a login on that box to turn themselves into superuser, which allows them to defeat SELinux.
Incidentally, it is possible to configure SSH to allow SFTP but not interactive logins. You should also chroot SFTP users. This thread seems to have the details you need:
https://www.CentOS.org/forums/viewtopic.php?t=2080
By doing that, even a bad user who gives away their login credentials to a bad actor isn’t opening you to a risk of a local root escalation exploit.
What is the context here? The big problem with ftp is that it passes the user credentials in the clear. There is nothing particularly wrong with an anonymous ftp download area where the files are put in place with something more secure – but it is usually easier to use http for that and you’ll have less trouble with firewalls.
Enough about FTP vs SFTP. This is exactly the kind of unhelpful discussion that I was referring to last month about the conversations on this list. CentOS is an *enterprise* distribution and as such it would be expected that people are either bound by corporate restrictions, or have some other requirements that you’re not aware of. A single helpful comment reminding someone that they should be using SFTP instead of FTP is the only appropriate thing to be saying here, not this dead-horse-beating.
So to actually address the stated problem… I don’t know about proftpd, but there’s a page here that discusses getting it working with selinux:
http://selinuxproject.org/page/FTPRecipes and I’m sure that clicking this link will lead you to other helpful documents:
https://www.google.com/search?q=proftpd+selinux+CentOS+7
It does require that you have an understanding of selinux, and are not just looking for a magic incantation to make it work. You can look at the audit log in /var/log/audit to get an idea of what is failing, and also the
‘audit2why’ and ‘audit2allow’ commands can help to suggest what selinux settings need to be changed or are getting in the way.
P.S. FTP is not secure, so you should try to use SFTP if you are able to influence the requirements.
❧ Brian Mathis
@orev
That seems like an awfully convenient rug to sweep problems under.
Can’t fix a security problem? Corporate restrictions!
Can’t require sensible security defaults restrictions by default? Corporate restrictions!
Can’t move off IE6? Corporate restrictions!
This seems like code for “We’d really rather computing in 2015 worked like computing in 1995.”
I’d say this continued “dead horse beating” is helpful. No one should come away from proposing a solution based on FTP in 2015 without being chastised for it.
Guys,
I hear all your arguments against using FTP. I completely get all that. But I am making things a little bit safer by using virtual users that have no access to the file system. The ftp user account has a shell of
/bin/false. And I was able to get proftpd working with SELinux using setsebool -P ftp_home_dir on.
The client is recalcitrant to using any technology he doesn’t know. I have tried explaining to him that SFTP would make things safer. But in the end it’s his money and his choice. He owns all the content he’s uploading, so it’s really his neck if it gets owned. But I think I’ve done a reasonable job of keeping things safe. Still open to criticism of course. And I
appreciate all your input.
Thanks, Tim
—
GPG me!!
gpg –keyserver pool.sks-keyservers.net –recv-keys F186197B
Oh and one important point I forgot to mention, is that the FTP user’s home directory is jailed.
Thanks!!
Tim
—
GPG me!!
gpg –keyserver pool.sks-keyservers.net –recv-keys F186197B