Bug 399381

In order to use create_dir_perms;  you must use the makefile in
/usr/share/selinux/devel/Makefile.

BTW if you want to allow ftpd to write to public_content you should relabel the
directory public_content_rw_t and set the allow_ftpd_anon_write boolean to true.

This is explained in man selinux_ftp

I do use this makefile. Actually, I have it organized this way:

$ ls
Makefile  tmp  server1_local.fc  server1_local.if  server1_local.pp 
server1_local.te
$ cat Makefile
server1_local.pp: server1_local.te
        make -f /usr/share/selinux/devel/Makefile


So in order to build the module, "make -f /usr/share/selinux/devel/Makefile" is
invoked.

BTW, you probably meant "man ftpd_selinux".
But the FTP-related module is just an example. The real problem is that macros
aren't used.

Requesting permission to reopen bug.

Yes, 

What error are you seeing when you execute this?  What does your te file look like?

The really dangerous thing is, there are noe errors when building and loading
this module, e.g. I've prepared a minimal module like this:

##############################
module ftpd_local 1.8;

require {
        class dir create_dir_perms;
        class file create_file_perms;
        type ftpd_t; 
        type public_content_t; 
};

allow ftpd_t public_content_t:dir create_dir_perms;
allow ftpd_t public_content_t:file create_file_perms;
##############################

It got compiled without any errors or warnings:

##############################
$ make -f /usr/share/selinux/devel/Makefile
Compiling targeted ftpd_local module
/usr/bin/checkmodule:  loading policy configuration from tmp/ftpd_local.tmp
/usr/bin/checkmodule:  policy configuration loaded
/usr/bin/checkmodule:  writing binary representation (version 6) to
tmp/ftpd_local.mod
Creating targeted ftpd_local.pp policy package
rm tmp/ftpd_local.mod.fc tmp/ftpd_local.mod

$ semodule -i ftpd_local.pp
##############################

But I still get AVC deny messages in /var/log/audit/audit.log:

##############################
type=AVC msg=audit(1196269013.629:815): avc:  denied  { write } for  pid=5821
comm="vsftpd" name="biblioteka" dev=xvda1 ino=1835025
scontext=system_u:system_r:ftpd_t:s0 tcontext=root:object_r:public_content_t:s0
tclass=dir
type=AVC msg=audit(1196269013.629:815): avc:  denied  { add_name } for  pid=5821
comm="vsftpd" name="temp" scontext=system_u:system_r:ftpd_t:s0
tcontext=root:object_r:public_content_t:s0 tclass=dir
##############################

I'll attach the module source together with compiled binary, a log of AVC
messages and checkmodule's tmp dir that it created when compiling the module.

Created attachment 271501 [details]
tgz that contains the simple example module source and binary, logs and tmp directory

Now this is getting quite bizarre. create_{dir,file}* macros half-work in this
seemingly analogous module:

##############################
module httpd_stunnel 1.0;

require {
        type httpd_t;
        type stunnel_etc_t;
        class dir create_dir_perms;
        class file create_file_perms;
}

#============= httpd_t ==============
allow httpd_t stunnel_etc_t:dir create_dir_perms;
allow httpd_t stunnel_etc_t:file create_file_perms;
##############################

I'm testing using this simple PHP script under Apache:

##############################
<?php

$handle = fopen("/etc/stunnel/backup-tism.conf", "r");

if ($handle) {
    while (!feof($handle)) {
        $buffer = fgets($handle, 4096);
        echo $buffer;
    }
    fclose($handle);
}
?>
##############################

Before loading this module, I get more AVC than after loading it.

AVC before loading httpd_stunnel:

##############################
type=AVC msg=audit(1196269875.919:838): avc:  denied  { getattr } for  pid=5258
comm="httpd" name="stunnel" dev=xvda1 ino=2097890
scontext=system_u:system_r:httpd_t:s0
tcontext=system_u:object_r:stunnel_etc_t:s0 tclass=dir
type=SYSCALL msg=audit(1196269875.919:838): arch=c000003e syscall=6 success=yes
exit=0 a0=7fff34debca0 a1=7fff34debb50 a2=7fff34debb50 a3=6 items=0 ppid=1386
pid=5258 auid=4294967295 uid=48 gid=48 euid=48 suid=48 fsuid=48 egid=48 sgid=48
fsgid=48 tty=(none) comm="httpd" exe="/usr/sbin/httpd"
subj=system_u:system_r:httpd_t:s0 key=(null)
type=AVC_PATH msg=audit(1196269875.919:838):  path="/etc/stunnel"
type=AVC msg=audit(1196269875.919:839): avc:  denied  { search } for  pid=5258
comm="httpd" name="stunnel" dev=xvda1 ino=2097890
scontext=system_u:system_r:httpd_t:s0
tcontext=system_u:object_r:stunnel_etc_t:s0 tclass=dir
type=AVC msg=audit(1196269875.919:839): avc:  denied  { getattr } for  pid=5258
comm="httpd" name="backup-tism.conf" dev=xvda1 ino=2261043
scontext=system_u:system_r:httpd_t:s0 tcontext=root:object_r:stunnel_etc_t:s0
tclass=file
##############################

AVC after loading AVC:
##############################
type=AVC msg=audit(1196269909.023:842): avc:  denied  { search } for  pid=4684
comm="httpd" name="stunnel" dev=xvda1 ino=2097890
scontext=system_u:system_r:httpd_t:s0
tcontext=system_u:object_r:stunnel_etc_t:s0 tclass=dir
##############################

That's quite strange, considering that in serefpolicy (I admin, I didn't look
into targeted policy sources) create_dir_perms includes search permission:

define(`create_dir_perms', `{ create read getattr lock setattr ioctl link unlink
rename search add_name remove_name reparent write rmdir }')


Note that I do all tests in permissive mode.

I'll attach the httpd_stunnel and related stuff in a minute.

Created attachment 271511 [details]
another tgz for httpd_stunnel module

Sorry, I've meant to type "I admit", not "I admin". Finger memory...

If you look in policy/support/obj_perm_sets.spt

you will see:

#
# Permissions for creating and using directories.
#
# deprecated by new perm set below
#define(`create_dir_perms', `{ create read getattr lock setattr ioctl link
unlink rename search add_name remove_name reparent write rmdir }')
...

define(`create_dir_perms',`{ getattr create }')


You should use manage_dir_perms 
to get all permissions.

IMHO when such changes break compatibility with previous releases, they should
be noted in release notes
(http://docs.fedoraproject.org/release-notes/f7/en_US/sn-Security.html#SELinux),
or in Fedora SELinux FAQ (whose latest version is currently for Fedora Core 5).