It seems to me that proftpd should be able to write this file without enabling it to write anything anywhere.

Yes any idea why this file is not in 

/var/run/proftpd  which should have the proper labeling for this.

chcon -t ftpd_var_run_t /var/run/proftpd* will fix. 


Miroslav

Lets change the labeling to

/var/run/proftpd.* 		gen_context(system_u:object_r:ftpd_var_run_t,s0)

(In reply to comment #2)
> Yes any idea why this file is not in 
> 
> /var/run/proftpd  which should have the proper labeling for this.

in /var/run/proftpd/ I have: proftpd.delay  proftpd.sock

But proftpd.score and proftpd.pid are one level up in /var/run.. 

Now the location of the scoreboard file is adjustable in proftpd.conf but I don't think it's been changed from the default.  Also the pid file shown in the init script matches what exists on my system.. Perhaps the proftpd package needs to be altered to put all these in /var/run/proftpd?

One other thing that's confusing me, the context reported by the audit is not the context on the file..

-rw-r--r--. root      root      system_u:object_r:ftpd_var_run_t:s0 proftpd.pid
-rw-r--r--. root      root      system_u:object_r:ftpd_var_run_t:s0 proftpd.score

...So why the denial?

At the time the avc happened it had the wrong label.  Yes these files should be put into the directory.  And we will also fix the label in case people do not have the fixed proftpd package.

The out of the box configuration of proftpd in Fedora does not include a ScoreboardFile directive in the configuration; the scoreboard file should therefore be written to the default location, which is /var/run/proftpd/proftpd.scoreboard. The PID file is also written to that directory by default.

If you have a ScoreboardFile directive in your proftpd.conf, it's probably a hangover from an update from an older version, and the changes from the current config haven't been merged in.

(In reply to comment #5)
> If you have a ScoreboardFile directive in your proftpd.conf, it's probably a
> hangover from an update from an older version, and the changes from the current
> config haven't been merged in.    

Quite likely, since the machine in question has been upgraded over time from Fedora 6.. It's difficult to catch every change.

I've altered my proftpd.conf to create the scoreboard within /var/run/proftpd/ and I'm not seeing the denial anymore.  I've also added a line "PidFile /var/run/proftpd/proftpd.pid" to the file to make sure it creates the pid file in there too, and altered the comment in /etc/init.d/proftpd to reflect the change.. apparently the default is to use /var/run/proftp.pid if this directive is not present.. Is that going to be changed in proftpd, or policy changed to allow the file outside of /var/run/proftpd?

When I was looking at my own system prior to making Comment #5 I ran "strings" on /usr/sbin/proftpd and found /var/run/proftpd/proftpd.pid. However, I'm running a build of proftpd 1.3.3rc3, not 1.3.2c as in Fedora, and it seems upstream has moved the PID file location between those releases.

I think that either /var/run/proftpd/proftpd.pid or /var/run/proftpd.pid are both sane places for the PID file though, and IMHO policy should support both. There are plenty of existing examples of daemons that have their own directory in /var/run but write their PID files directly under /var/run.

Just updated to 1.3.3rc4 and got this AVC:

time->Mon Feb 15 10:22:23 2010
type=SYSCALL msg=audit(1266229343.222:225193): arch=c000003e syscall=121 success=no exit=-13 a0=37ea a1=0 a2=37ea a3=7fffddeb8f80 items=0 ppid=1 pid=14091 auid=0 uid=0 gid=99 euid=0 suid=0 fsuid=0 egid=0 sgid=99 fsgid=0 tty=(none) ses=20978 comm="proftpd" exe="/usr/sbin/proftpd" subj=unconfined_u:system_r:ftpd_t:s0-s0:c0.c1023 key=(null)
type=AVC msg=audit(1266229343.222:225193): avc:  denied  { getpgid } for  pid=14091 comm="proftpd" scontext=unconfined_u:system_r:ftpd_t:s0-s0:c0.c1023 tcontext=unconfined_u:system_r:ftpd_t:s0-s0:c0.c1023 tclass=process

It originates from the scoreboard code again:

int pr_scoreboard_entry_kill(pr_scoreboard_entry_t *sce, int signo) {
  int res;

  if (sce == NULL) {
    errno = EINVAL;
    return -1;
  }

  if (ServerType == SERVER_STANDALONE) {
#ifdef HAVE_GETPGID
    pid_t curr_pgrp;

# ifdef HAVE_GETPGRP
    curr_pgrp = getpgrp();
# else
    curr_pgrp = getpgid(0);
# endif /* HAVE_GETPGRP */

    if (getpgid(sce->sce_pid) != curr_pgrp) {
      pr_trace_msg(trace_channel, 1, "scoreboard entry PID %lu process group "
        "does not match current process group, refusing to send signal",
        (unsigned long) sce->sce_pid);
      errno = EPERM;
      return -1;
    }
#endif /* HAVE_GETPGID */
  }

  res = kill(sce->sce_pid, signo);
  return res;
}

So it would seem proftpd needs this permission.

Miroslav, also add this access.

I'll be updating proftpd in Fedora to 1.3.2d soon.

Can the EL-5 policy be updated too as it would be good to update EPEL as well?

Fixed in selinux-policy-3.6.32-91.fc12

proftpd-1.3.2d-1.fc12 is in updates-testing now.

This, in conjunction with selinux-policy-3.6.32-91.fc12, should work without needing PidFile or ScoreboardFile directives in proftpd.conf.

I have installed the updated proftpd but yum still cannot find the new selinux-policy.  I will retest when yum can see it.

I am going to push out F-12 update today.

selinux-policy-3.6.32-92.fc12 has been submitted as an update for Fedora 12.
http://admin.fedoraproject.org/updates/selinux-policy-3.6.32-92.fc12

selinux-policy-3.6.32-92.fc12 has been pushed to the Fedora 12 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/F12/FEDORA-2010-2953

selinux-policy-3.6.32-92.fc12 has been pushed to the Fedora 12 stable repository.  If problems still persist, please make note of it in this bug report.