Bug 518569

Miroslav, Dan, any advice on this?

Miroslav can you add the following.


ifdef(`enable_mcs',`
	init_ranged_daemon_domain(ftpd_t, ftpd_exec_t, s0 - mcs_systemhigh)
')

ifdef(`enable_mls',`
	init_ranged_daemon_domain(ftpd_t, ftpd_exec_t, mls_systemhigh)
')

Fixed in selinux-policy-3.6.12-80.fc11

selinux-policy-3.6.12-80.fc11 has been submitted as an update for Fedora 11.
http://admin.fedoraproject.org/updates/selinux-policy-3.6.12-80.fc11

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

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?

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.

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

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.

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.

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).

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.

I can try to make a patch if someone can give me few pointers on how.

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.

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.

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.