selinux problem

Support for security such as Firewalls and securing linux
Post Reply
nabrantes
Posts: 9
Joined: 2012/04/05 09:04:06

selinux problem

Post by nabrantes » 2012/05/31 14:56:26

Hi there

I'm going nuts with seLinux framework.

I had a properly setup Centos 5.8 with (compiled) OpenSSH 5.9 chrooting users with sftponly no problem.

But I really need to make things easier with system updates and I also needed to have apache >= 2.2.15 so I decided to replicate the enviroment with Centos 6.2

I have the setup/installation process well documented so I did.

Problem is seLinux is behaving differently from 5.8 to 6.2 and I'm not being able to use sftp with a defined user, I am enable to connect and chdir but unable to list or put.

Some sebool parameters i did

setsebool -P ftp_home_dir=on;
setsebool -P allow_ftpd_full_access=on; #I also have vsftp
setsebool -P httpd_can_network_relay=1; #I also have net2ftp web app
setsebool -P ssh_chroot_rw_homedirs on;


Tried to change context for 1 test users and I have an error..

/sbin/restorecon -R -v /sftpjails/nasftp/home/nasftp
/sbin/restorecon reset /sftpjails/nasftp/home/nasftp context unconfined_u:object_r:default_t:s0->unconfined_u:object_r:chroot_user_t:s0
/sbin/restorecon set context /sftpjails/nasftp/home/nasftp->unconfined_u:object_r:chroot_user_t:s0 failed:'Permission denied'


I really need help.. I'm getting quite frustrated.

pschaff
Retired Moderator
Posts: 18276
Joined: 2006/12/13 20:15:34
Location: Tidewater, Virginia, North America
Contact:

selinux problem

Post by pschaff » 2012/05/31 15:01:59

Are you still using a replacement for openssh? If so, from a package or a [url=http://wiki.centos.org/PackageManagement/SourceInstalls]Source Install[/url]?

Have you tried putting SELinux in permissive mode and using [url=https://www.centos.org/search.php?query=audit2allow&mid=30&action=showall&andor=AND]audit2allow[/url]?

nabrantes
Posts: 9
Joined: 2012/04/05 09:04:06

Re: selinux problem

Post by nabrantes » 2012/05/31 15:27:15

No I'm using default Centos 6.2 openssh-server-5.3p1-70.el6_2.2.x86_64

In permissive mode it works fine.

I've used sealert -a from setroubleshoot but I have A LOT of stuff complaining and I'm not pinpointing the specific problem... (see below)

I don't understand why I need to force context to user_home_t on the blank file I use to tests, shouln't the context be defined by default.

I don't understand what differs from 5.8 (openssh 5.9) and standard 6.2 (openssh 5.3) I didn't had to do anything on the previous instalation.

I need to deliver the server.. I'm going nuts with this.

Btw to contextualize this is a vsftp/sftp with net2ftp server, vsftpd users can't do sftp and sftp users can't do vsftp (ftpusers exclusion) and there are users that have full access (fullssh group).

sshd -T

# sshd -T
port 22
protocol 2,1
addressfamily any
listenaddress 0.0.0.0:22
listenaddress [::]:22
usepam 1
serverkeybits 1024
logingracetime 120
keyregenerationinterval 3600
x11displayoffset 10
maxauthtries 6
maxsessions 10
clientaliveinterval 0
clientalivecountmax 3
permitrootlogin yes
ignorerhosts yes
ignoreuserknownhosts no
rhostsrsaauthentication no
hostbasedauthentication no
hostbasedusesnamefrompacketonly no
rsaauthentication yes
pubkeyauthentication yes
kerberosauthentication no
kerberosorlocalpasswd yes
kerberosticketcleanup yes
gssapiauthentication no
gssapicleanupcredentials yes
passwordauthentication yes
kbdinteractiveauthentication yes
challengeresponseauthentication yes
printmotd yes
printlastlog yes
x11forwarding no
x11uselocalhost yes
strictmodes yes
tcpkeepalive yes
permitemptypasswords no
permituserenvironment no
uselogin no
compression delayed
gatewayports no
showpatchlevel no
usedns yes
allowtcpforwarding yes
useprivilegeseparation yes
kerberosusekuserok yes
pidfile /var/run/sshd.pid
xauthlocation /usr/bin/xauth
authorizedkeysfile .ssh/authorized_keys
authorizedkeysfile2 .ssh/authorized_keys
loglevel INFO
syslogfacility AUTH
hostkey /etc/ssh/ssh_host_key
hostkey /etc/ssh/ssh_host_rsa_key
hostkey /etc/ssh/ssh_host_dsa_key
allowgroups fullssh
allowgroups sftponly
subsystem sftp internal-sftp
maxstartups 10:100:10
permittunnel no
permitopen any


Permissions:

#ls -ldZ /sftpjails
drwxr-x---. root root unconfined_u:object_r:default_t:s0 /sftpjails
#ls -ldZ /sftpjails/nasftp/
drwxr-xr-x. root root unconfined_u:object_r:default_t:s0 /sftpjails/nasftp/
#ls -ldZ /sftpjails/nasftp/home/
drwxr-xr-x. root root unconfined_u:object_r:default_t:s0 /sftpjails/nasftp/home/
#ls -ldZ /sftpjails/nasftp/home/nasftp
drwxrwx---. nasftp nasftp unconfined_u:object_r:default_t:s0 /sftpjails/nasftp/home/nasftp
#

SETroubleshoot information:

# sealert -a /var/log/audit/audit.log
100% donefound 2 alerts in /var/log/audit/audit.log
--------------------------------------------------------------------------------

SELinux is preventing /usr/sbin/sshd from read access on the directory /sftpjails/nasftp/home/nasftp.

***** Plugin restorecon (94.8 confidence) suggests *************************

If you want to fix the label.
/sftpjails/nasftp/home/nasftp default label should be chroot_user_t.
Then you can run restorecon.
Do
# /sbin/restorecon -v /sftpjails/nasftp/home/nasftp

***** Plugin catchall_labels (5.21 confidence) suggests ********************

If you want to allow sshd to have read access on the nasftp directory
Then you need to change the label on /sftpjails/nasftp/home/nasftp
Do
# semanage fcontext -a -t FILE_TYPE '/sftpjails/nasftp/home/nasftp'
where FILE_TYPE is one of the following: device_t, etc_t, chroot_user_t, var_run_t, user_home_dir_t, sysctl_crypto_t, abrt_t, user_home_t, lib_t, root_t, usr_t, home_root_t, user_home_dir_t, nfs_t, nfs_t, user_home_t, user_home_type.
Then execute:
restorecon -v '/sftpjails/nasftp/home/nasftp'


***** Plugin catchall (1.44 confidence) suggests ***************************

If you believe that sshd should be allowed read access on the nasftp directory by default.
Then you should report this as a bug.
You can generate a local policy module to allow this access.
Do
allow this access for now by executing:
# grep sshd /var/log/audit/audit.log | audit2allow -M mypol
# semodule -i mypol.pp


--------------------------------------------------------------------------------

SELinux is preventing /usr/sbin/sshd from getattr access on the file /home/nasftp/envia.blank.

***** Plugin restorecon (94.8 confidence) suggests *************************

If you want to fix the label.
/home/nasftp/envia.blank default label should be user_home_t.
Then you can run restorecon.
Do
# /sbin/restorecon -v /home/nasftp/envia.blank

***** Plugin catchall_labels (5.21 confidence) suggests ********************

If you want to allow sshd to have getattr access on the envia.blank file
Then you need to change the label on /home/nasftp/envia.blank
Do
# semanage fcontext -a -t FILE_TYPE '/home/nasftp/envia.blank'
where FILE_TYPE is one of the following: abrt_helper_exec_t, ld_so_t, textrel_shlib_t, rpm_script_tmp_t, chroot_user_t, rpm_tmp_t, ld_so_cache_t, abrt_var_cache_t, abrt_var_run_t, sysctl_crypto_t, abrt_t, user_home_t, lib_t, user_home_type, nfs_t, nfs_t, user_home_t, user_home_type.
Then execute:
restorecon -v '/home/nasftp/envia.blank'


***** Plugin catchall (1.44 confidence) suggests ***************************

If you believe that sshd should be allowed getattr access on the envia.blank file by default.
Then you should report this as a bug.
You can generate a local policy module to allow this access.
Do
allow this access for now by executing:
# grep sshd /var/log/audit/audit.log | audit2allow -M mypol
# semodule -i mypol.pp

pschaff
Retired Moderator
Posts: 18276
Joined: 2006/12/13 20:15:34
Location: Tidewater, Virginia, North America
Contact:

Re: selinux problem

Post by pschaff » 2012/05/31 16:50:26

I'd be prone to implement the suggestions given by sealert.

nabrantes
Posts: 9
Joined: 2012/04/05 09:04:06

Re: selinux problem

Post by nabrantes » 2012/05/31 18:38:57

Now I feel stupid..

A while ago I run
/sbin/restorecon -R -v /sftpjails/nasftp/home/nasftp
/sbin/restorecon reset /sftpjails/nasftp/home/nasftp context unconfined_u:object_r:default_t:s0->unconfined_u:object_r:chroot_user_t:s0
/sbin/restorecon set context /sftpjails/nasftp/home/nasftp->unconfined_u:object_r:chroot_user_t:s0 failed:'Permission denied'

And it gave me an error (permission denied)

Now it didn't and everything is working... (I did a reboot, maybe all the enforce, permissive, enforce, permissive, mess something up)

I hate when stuff starts working without me fully understanding what happened..

Thanks pschaff, lets see if this maintains a consistent behavior

Cheers
Nuno Abrantes

pschaff
Retired Moderator
Posts: 18276
Joined: 2006/12/13 20:15:34
Location: Tidewater, Virginia, North America
Contact:

Re: selinux problem

Post by pschaff » 2012/06/01 01:16:50

[quote]
nabrantes wrote:
...
I hate when stuff starts working without me fully understanding what happened..[/quote]
Me too. Things that fix themselves may break themselves with equal ease. Please keep us posted.

sbonds
Posts: 5
Joined: 2014/09/19 08:17:48

Re: selinux problem

Post by sbonds » 2018/02/26 21:41:42

I realize this is a reply to a truly ancient posting, but Google came up with this as a match to a problem I was having with sftp and chroot jails-- and it was right!

However, I did ultimately find a solution.

To search for selinux rules that may apply for a given source/target context (thanks, https://wiki.centos.org/HowTos/SELinux):

Code: Select all

# sesearch --allow --show_cond --regex --source chroot_user_t --class file -p write --target public
This led me to the selinux boolean "ssh_chroot_full_access" which allows lots of things, including public_content_rw_t access.

Code: Select all

# semanage fcontext -a -t public_content_rw_t "/sftpdirectory/(.*)?"
# restorecon -F -R -v /sftpdirectory/
# setsebool -P ssh_chroot_full_access=1
# service sshd restart
And presto! It works! sftp can now write to /sftpdirectory.

Post Reply