Bug 508138 - SELinux is preventing vsftpd (ftpd_t) "sys_admin" ftpd_t
SELinux is preventing vsftpd (ftpd_t) "sys_admin" ftpd_t
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: selinux-policy (Show other bugs)
11
All Linux
low Severity medium
: ---
: ---
Assigned To: Jiri Skala
Fedora Extras Quality Assurance
:
: 508654 509601 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2009-06-25 15:29 EDT by Allen Kistler
Modified: 2014-11-09 17:31 EST (History)
10 users (show)

See Also:
Fixed In Version: selinux-policy-3.6.12-62.fc11.noarch
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-07-11 17:29:40 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Allen Kistler 2009-06-25 15:29:24 EDT
Description of problem:
Connections to vsftpd fail after updating vsftpd.  AVC denials logged.
Strangely, "setenforce 0" allows the connections, but *doesn't* log anything.

Version-Release number of selected component (if applicable):
selinux-policy-3.6.12-53.fc11.noarch
vsftpd-2.1.2-1.fc11.i586

How reproducible:
Always

Steps to Reproduce:
1. try to connect to ftp server (e.g., "ftp ack602")
  
Actual results:
Connected to ack602.
421 Service not available, remote server has closed connection

Expected results:
Connected to ack602.
220 (vsFTPd 2.1.2)
530 Please login with USER and PASS.
Name (ack602:allen):

Additional info:

node=ack602 type=AVC msg=audit(1245957040.795:82): avc:  denied  { sys_admin } for  pid=2338 comm="vsftpd" capability=21 scontext=unconfined_u:system_r:ftpd_t:s0 tcontext=unconfined_u:system_r:ftpd_t:s0 tclass=capability
Comment 1 Daniel Walsh 2009-06-26 11:18:38 EDT
vsftpd should not require this access?  Could you include the entire AVC message including the SYSCALL data from either the setroubleshoot, or 

ausearch -m AVC

We need to see what syscall is causing this.

If you just want this to work you can

# grep avc /var/log/audit/audit.log | audit2allow -M mypol
# semodule -i mypol.pp

I believe this is either a configuration problem of a vsftpd bug.
Comment 2 Allen Kistler 2009-06-26 14:49:02 EDT
I'm still puzzled by why nothing at all is logged in permissive mode, but here's the entire message, including the SYSCALL, from enforcing mode.

type=AVC msg=audit(1245957040.795:82): avc:  denied  { sys_admin } for  pid=2338 comm="vsftpd" capability=21 scontext=unconfined_u:system_r:ftpd_t:s0 tcontext=unconfined_u:system_r:ftpd_t:s0 tclass=capability

type=SYSCALL msg=audit(1245957040.795:82): arch=40000003 syscall=120 success=no exit=-1 a0=28000011 a1=0 a2=727334 a3=727334 items=0 ppid=1 pid=2338 auid=500 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=5 comm="vsftpd" exe="/usr/sbin/vsftpd" subj=unconfined_u:system_r:ftpd_t:s0 key=(null)
Comment 3 Eric Paris 2009-06-26 14:57:58 EDT
Things are only logged once in permissive, the second time the allow is already cached so you don't get a denial.  Likely you just missed it the first time.

type=SYSCALL msg=audit(06/25/2009 15:10:40.795:82) : arch=i386 syscall=clone success=no exit=-1(Operation not permitted) a0=28000011 a1=0 a2=727334 a3=727334 items=0 ppid=1 pid=2338 auid=paris uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=(none) ses=5 comm=(null) exe=(null) subj=unconfined_u:system_r:ftpd_t:s0 key=(null) 

type=AVC msg=audit(06/25/2009 15:10:40.795:82) : avc:  denied  { sys_admin } for pid=2338 comm=(null) capability=sys_admin scontext=unconfined_u:system_r:ftpd_t:s0 tcontext=unconfined_u:system_r:ftpd_t:s0 tclass=capability 


/me goes to check out sys_clone....
Comment 4 Eric Paris 2009-06-26 15:06:15 EDT
man clone(2)

int clone(int (*fn)(void *), void *child_stack,
          int flags, void *arg, ...
so:
 a0= function pointer.
 a1= child stack pointer
 a2= clone flags
 a3= arg

in the above syscall

a0=28000011
a1=0
a2=727334
a3=727334

So what the heck is a2=727334?   That's a dang lot of clone flags:

CLONE_FS CLONE_VM CLONE_VFORK CLONE_PTRACE CLONE_NEWNS CLONE_PARENT_SETTID CLONE_CHILD_CLEARTID CLONE_DETACHED + some unknown 0x00001000

And look, CLONE_NEWNS  REQUIRES cap_sysadm according to the web page.  So why is vsftpd trying to create a new namespace?
Comment 5 Daniel Walsh 2009-06-26 15:34:12 EDT
Is pam_namespace in the ftp stack?
Comment 6 Allen Kistler 2009-06-28 17:50:59 EDT
FWIW, whatever vsftpd-2.1.2-1.fc11 (F11 updates) is trying to do with sys_admin, vsftpd-2.1.0-2.fc11 (F11 DVD) didn't.

Also, on my machine /etc/pam.d/vsftpd is ...

session    optional     pam_keyinit.so    force revoke
auth       required     pam_listfile.so item=user sense=deny file=/etc/vsftpd/ft
pusers onerr=succeed
auth       required     pam_shells.so
auth       include      system-auth
account    include      system-auth
session    include      system-auth
session    required     pam_loginuid.so

... and system-auth is ...

auth        required      pam_env.so
auth        sufficient    pam_unix.so nullok try_first_pass
auth        requisite     pam_succeed_if.so uid >= 500 quiet
auth        required      pam_deny.so

account     required      pam_unix.so
account     sufficient    pam_localuser.so
account     sufficient    pam_succeed_if.so uid < 500 quiet
account     required      pam_permit.so

password    requisite     pam_cracklib.so try_first_pass retry=3
password    sufficient    pam_unix.so sha512 shadow nullok try_first_pass use_au
thtok
password    required      pam_deny.so

session     optional      pam_keyinit.so revoke
session     required      pam_limits.so
session     [success=1 default=ignore] pam_succeed_if.so service in crond quiet 
use_uid
session     required      pam_unix.so

... both of which are the default.

Is there another way pam_namespace could/would sneak in?
Comment 7 Miroslav Grepl 2009-06-29 07:12:30 EDT
*** Bug 508654 has been marked as a duplicate of this bug. ***
Comment 8 Daniel Walsh 2009-06-29 09:53:37 EDT
No I don't think pam_namespace is the problem, pam_mount could have also caused this.  

cap_sysadm is required for the following

CAP_SYS_ADMIN

	Allow configuration of the secure attention key;
	Allow administration of the random device;
	Allow examination and configuration of disk quotas;
	Allow configuring the kernel's syslog (printk behaviour);
	Allow setting the domainname;
	Allow setting the hostname;
	Allow calling bdflush();
	Allow mount() and umount(), setting up new smb connection;
	Allow some autofs root ioctls;
	Allow nfsservctl; Allow VM86_REQUEST_IRQ;
	Allow to read/write pci config on alpha; Allow irix_prctl on mips 
(setstacksize);
	Allow flushing all cache on m68k (sys_cacheflush);
	Allow removing semaphores; Used instead of CAP_CHOWN to "chown" IPC 
message queues, semaphores and shared memory;
	Allow locking/unlocking of shared memory segment;
	Allow turning swap on/off;
	Allow forged pids on socket credentials passing;
	Allow setting readahead and flushing buffers on block devices;
	Allow setting geometry in floppy driver;
	Allow turning DMA on/off in xd driver;
	Allow administration of md devices (mostly the above, but some extra 
ioctls);
	Allow tuning the ide driver;
	Allow access to the nvram device;
	Allow administration of apm_bios, serial and bttv (TV) device;
	Allow manufacturer commands in isdn CAPI support driver;
	Allow reading nonstandardized portions of pci configuration space;
	Allow DDI debug ioctl on sbpcd driver;
	Allow setting up serial ports;
	Allow sending raw qic117 commands;
	Allow enabling/disabling tagged queuing on SCSI controllers and sending 
arbitrary SCSI commands;
	Allow setting encryption key on loopback filesystem.

Is there anything in vsftpd that could be requiring this access?
Comment 9 Eric Paris 2009-06-29 14:52:14 EDT
Sorry to send everyone down the wrong path....

man (2) clone != sys_clone().  Noticed I got my arguments above from man (2) clone.  So I did a bit more digging today.

In arch/x86/kernel/process_32.c sys_clone is defined:

int sys_clone(struct pt_regs *regs)

and if we look inside the function we see:

clone_flags = regs->bx;

So we know the clone_flags are in regs->bx.  So now lets looks at how the syscall argument is created.  That would happen in:

arch/x86/kernel/ptrace.c::syscall_trace_enter() in which we call:
audit_syscall_entry(AUDIT_ARCH_I386, regs->orig_ax, regs->bx, regs->cx, regs->dx, regs->si);

so regs->bx (which holds the clone_flags) is passed to audit_syscall_entry as the 3rd argument.  So we go check out kernel/auditsc.c::audit_syscall_entry()

void audit_syscall_entry(int arch, int major,
                         unsigned long a1, unsigned long a2,
                         unsigned long a3, unsigned long a4) {
...
       context->argv[0]    = a1;
...
}

So a1 (which is regs->bx which is clone_flags) is now stored in argv[0];

Now in audit_log_exit() when we emitted the SYSCALL record we have:
        audit_log_format(ab,
                  " a0=%lx a1=%lx a2=%lx a3=%lx items=%d"
[snip]
                  context->argv[0],
                  context->argv[1],
                  context->argv[2],
                  context->argv[3],
                  context->name_count,
[snip]

So after all of that we see that in the SYSCALL record a0 -> a1 -> regs->bx -> clone_flags.

WHEW.

So now back to the SYSCALL record:
type=SYSCALL msg=audit(1245957040.795:82): arch=40000003 syscall=120 success=no
exit=-1 a0=28000011 a1=0 a2=727334 a3=727334 items=0 ppid=1 pid=2338 auid=500
uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=5
comm="vsftpd" exe="/usr/sbin/vsftpd" subj=unconfined_u:system_r:ftpd_t:s0
key=(null)

so a0=28000011

Now the same mapping back to clone flags as I did (incorrectly) in comment #4:

0x11 = 17 = SIGCHLD

a0 = ( CLONE_NEWPID | CLONE_IPC | SIGCHLD )

both CLONE_NEWPID and CLONE_NEWIPC can require CAP_SYS_ADMIN according to the man page.

So lets looks at the vsftpd source.  Namely vsftpd-2.1.2/sysdeputil.c::vsf_sysutil_fork_isolate_failok() where it calls (you guessed it!)

    int ret = syscall(__NR_clone, CLONE_NEWPID | CLONE_NEWIPC | SIGCHLD, NULL);

Tada, calls which require CAP_SYS_ADMIN.  Now don't ask me why vsftpd is doing it, or why it didn't do it.  That's for the vsftpd maintainer to tell us....

-Eric
Comment 10 Daniel Walsh 2009-06-29 16:20:33 EDT
vsf_sysutil_fork_isolate_failok() so fails is not ok?
Comment 11 Daniel Walsh 2009-06-29 16:21:35 EDT
I have send Miroslav a patch that allows this for now, so people's vsftpd will work.
Comment 13 Miroslav Grepl 2009-06-29 16:43:53 EDT
(In reply to comment #11)
> I have send Miroslav a patch that allows this for now, so people's vsftpd will
> work.  

Added to selinux-policy-3.6.12-61.fc11
Comment 14 Miroslav Grepl 2009-07-07 03:30:37 EDT
*** Bug 509601 has been marked as a duplicate of this bug. ***
Comment 15 Allen Kistler 2009-07-08 18:54:19 EDT
I snagged selinux-policy-3.6.12-65.fc11 from koji and verified the fix.

When the policy hits updates, should I close this bug or leave it open?
Is it the intent that the policy change is temporary?
Basically, should this report serve as a reminder to find out why the latest vsftpd thinks it needs the access?
Comment 16 Daniel Walsh 2009-07-09 08:37:45 EDT
No this looks like a permanent change.  So it should be closed.

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