Bug 518569 - ls: Login failed: 500 OOPS: cannot change directory
Summary: ls: Login failed: 500 OOPS: cannot change directory
Alias: None
Product: Fedora
Classification: Fedora
Component: selinux-policy
Version: 11
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Miroslav Grepl
QA Contact: Fedora Extras Quality Assurance
Depends On:
TreeView+ depends on / blocked
Reported: 2009-08-20 23:16 UTC by Seramal
Modified: 2009-08-28 21:56 UTC (History)
5 users (show)

Fixed In Version: 3.6.12-80.fc11
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2009-08-28 21:56:51 UTC
Type: ---

Attachments (Terms of Use)

Description Seramal 2009-08-20 23:16:10 UTC
Description of problem:

vsftpd fails to change security context when enforcing mls/mcs.

Version-Release number of selected component (if applicable):

How reproducible:
# semanage user -m -r s0-s0:c0.c1023 user_u
# groupadd testing
# useradd -m -g testing -Z user_u testing
# semanage login -m -r s0:c3 testing
# chcon -R -l s0:c3 /home/testing
# /etc/init.d/vsftpd start
# lftp
open -u testing,password localhost
Actual results:
The 'ls' command is denied by the policy because the user's home directory has mls s0:c3 and vsftpd does not change it's security context to match the user's security context: s0:c3.

Expected results:
vsftpd is running with unconfined_u:system_r:ftpd_t:s0, and should be running with unconfined_u:system_r:ftpd_t:s0-s0:c0.c1023 so it could DROP PRIVILEGES after forking to match the user logging in.

Comment 1 Martin Nagy 2009-08-21 09:04:36 UTC
Miroslav, Dan, any advice on this?

Comment 2 Daniel Walsh 2009-08-21 19:34:18 UTC
Miroslav can you add the following.

	init_ranged_daemon_domain(ftpd_t, ftpd_exec_t, s0 - mcs_systemhigh)

	init_ranged_daemon_domain(ftpd_t, ftpd_exec_t, mls_systemhigh)

Comment 3 Miroslav Grepl 2009-08-24 15:37:09 UTC
Fixed in selinux-policy-3.6.12-80.fc11

Comment 4 Fedora Update System 2009-08-24 15:44:43 UTC
selinux-policy-3.6.12-80.fc11 has been submitted as an update for Fedora 11.

Comment 5 Fedora Update System 2009-08-25 04:26:27 UTC
selinux-policy-3.6.12-80.fc11 has been pushed to the Fedora 11 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update selinux-policy'.  You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F11/FEDORA-2009-8895

Comment 6 Seramal 2009-08-26 02:52:39 UTC
I upgraded to selinux-policy-3.6.12-80.fc11, rebooted, and the problem remains. I believe it's not enough to modify selinux policy. 

vsftpd starts running with a privileged UID (0). Upon receiving a connection, it forks a new process to handle the connection and drops privileges to match the current user. The problem is that vsftpd starts running in s0, and should start in s0-s0:c0.c1023 (root) and then drop privileges to the user's mls/mcs just like it does with uid. 

In my example it should start with root (whatever_u:whatever_r:whatever_t:s0-s0:c0.c1023)  and then go to testing (whatever_u:whatever_r:whatever_t:s0.c3)

I believe this can only be solved by using selinux/context.h and context_range_set() in vsftpd, right?

Comment 7 Martin Nagy 2009-08-26 05:36:51 UTC
I'm not familiar with these selinux functions. If someone can explain in more details what needs to be done or point me to relevant documentation then I can make a patch and even propose it to the upstream.

Comment 8 Daniel Walsh 2009-08-26 12:46:16 UTC
ftp currently does not have selinux functions built in.  So the process runs with the range of levels that it gets started with.

To make this truly multi level, you would have to add use the setcon function along with the setuid function in vsftp.  Does vsftp do an exec to handle the process?  If yes then we could do a setexeccon.  I would like to know if this is a requirement of MLS environments though.  I am not sure what Seramal is tying to do it worth it in a Targeted system

Comment 9 Martin Nagy 2009-08-26 13:08:49 UTC
Dan, I'm not sure what you meant by handling the process with an exec, but a quick grep reveals that vsftpd doesn't use exec anywhere.

Comment 10 Daniel Walsh 2009-08-26 13:14:03 UTC
So the question then would it be worth it to change vsftp to do a "setcon" call after the fork/setuid call.  This would change the context of the process running on behalf of the user.

Currently the vsftp daemon continues to run in the context of vsftp at the range that was designated.  

Theoretically it could drop privs and levels.

Comment 11 Seramal 2009-08-26 20:14:56 UTC
IMHO if the process is designed to drop privileges, it should drop privileges on everything, not just UID/GID.

I think it would enhance security on mls/mcs systems and wouldn't harm the normal users because by default user_u and [x]guest_u run with s0. 

And of course, it would allow more paranoid selinux users like me to use ftpd instead of using sftp (sshd/pam changes mls/mcs to match the user).

Comment 12 Seramal 2009-08-27 00:32:28 UTC
Another thing, I could easily fix the issue by allowing vsftpd to run with s0-s0:c0.c1023, but then every user would have mls/mcs clearance on each other files.

Comment 13 Martin Nagy 2009-08-27 05:57:45 UTC
I can try to make a patch if someone can give me few pointers on how.

Comment 14 Daniel Walsh 2009-08-27 12:59:54 UTC
Lets bring this up for discussion on the SELinux list.

There are two possibilities, here,  One is to just change the level on the vstfpd process to run at the appropriate level of the user.  The second would be to change the type, in order to run as a type appropriate for the user.  IE With different privs then the vsftpd server.

Comment 15 Seramal 2009-08-27 14:42:04 UTC
I think the important thing is to change the level to allow MLS systems to work, but of course if someone would take the time to create a policy for vsftpd, it would be great to have a different type.

Comment 16 Fedora Update System 2009-08-28 21:56:25 UTC
selinux-policy-3.6.12-80.fc11 has been pushed to the Fedora 11 stable repository.  If problems still persist, please make note of it in this bug report.

Note You need to log in before you can comment on or make changes to this bug.