Description of problem: SELinux denied access requested by in.tftpd. Selecting the existing SELinux Boolean "tftp" does not allow a device (e.g. Cisco switch) to write data to the tftp folder. In Permissive mode tftp works but with a SELinux warning. Version-Release number of selected component (if applicable): Fedora 11. tftp-server-0.49-3.fc11.x86_64 selinux-policy-targeted-3.6.12-62.fc11.noarch How reproducible: Always. Steps to Reproduce: 1. Install tftp-server. 2. Enable the server in xinetd.d folder. Change server_args = -cvvs /tftpboot 3. Restart xinetd 4. Request a device to write a config file to your Fedora host. Actual results: Summary: SELinux is preventing in.tftpd (tftpd_t) "write" tftpdir_t. Detailed Description: [SELinux is in permissive mode, the operation would have been denied but was permitted due to permissive mode.] SELinux denied access requested by in.tftpd. It is not expected that this access is required by in.tftpd and this access may signal an intrusion attempt. It is also possible that the specific version or configuration of the application is causing it to require additional access. Allowing Access: You can generate a local policy module to allow this access - see FAQ (http://fedora.redhat.com/docs/selinux-faq-fc5/#id2961385) Or you can disable SELinux protection altogether. Disabling SELinux protection is not recommended. Please file a bug report (http://bugzilla.redhat.com/bugzilla/enter_bug.cgi) against this package. Additional Information: Source Context system_u:system_r:tftpd_t:s0-s0:c0.c1023 Target Context system_u:object_r:tftpdir_t:s0 Target Objects /tftpboot [ dir ] Source in.tftpd Source Path /usr/sbin/in.tftpd Port <Unknown> Host lvd-pc.localdomain Source RPM Packages tftp-server-0.49-3.fc11 Target RPM Packages Policy RPM selinux-policy-3.6.12-62.fc11 Selinux Enabled True Policy Type targeted MLS Enabled True Enforcing Mode Permissive Plugin Name catchall Host Name lvd-pc.localdomain Platform Linux lvd-pc.localdomain 2.6.29.5-191.fc11.x86_64 #1 SMP Tue Jun 16 23:23:21 EDT 2009 x86_64 x86_64 Alert Count 7 First Seen Wed 15 Jul 2009 11:31:43 AM WAT Last Seen Wed 15 Jul 2009 11:36:01 AM WAT Local ID 95aa8eca-701e-4c5d-b243-a37b763b17a1 Line Numbers Raw Audit Messages node=lvd-pc.localdomain type=AVC msg=audit(1247654161.234:60): avc: denied { write } for pid=6220 comm="in.tftpd" name="tftpboot" dev=dm-0 ino=15007778 scontext=system_u:system_r:tftpd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:tftpdir_t:s0 tclass=dir node=lvd-pc.localdomain type=AVC msg=audit(1247654161.234:60): avc: denied { add_name } for pid=6220 comm="in.tftpd" name="eikest02-confg" scontext=system_u:system_r:tftpd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:tftpdir_t:s0 tclass=dir node=lvd-pc.localdomain type=AVC msg=audit(1247654161.234:60): avc: denied { create } for pid=6220 comm="in.tftpd" name="eikest02-confg" scontext=system_u:system_r:tftpd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:tftpdir_t:s0 tclass=file node=lvd-pc.localdomain type=AVC msg=audit(1247654161.234:60): avc: denied { write } for pid=6220 comm="in.tftpd" name="eikest02-confg" dev=dm-0 ino=15007986 scontext=system_u:system_r:tftpd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:tftpdir_t:s0 tclass=file node=lvd-pc.localdomain type=SYSCALL msg=audit(1247654161.234:60): arch=c000003e syscall=2 success=yes exit=1 a0=608de2 a1=41 a2=1b6 a3=4000 items=0 ppid=6045 pid=6220 auid=4294967295 uid=99 gid=99 euid=99 suid=99 fsuid=99 egid=99 sgid=99 fsgid=99 tty=(none) ses=4294967295 comm="in.tftpd" exe="/usr/sbin/in.tftpd" subj=system_u:system_r:tftpd_t:s0-s0:c0.c1023 key=(null) Expected results: The config file should just have been written to the /tftpboot folder without an SELinux error. Additional info:
Can you change the label on the directory to tftpdir_rw_t. Usually tftpd_t is not allowed to write to the content, so you need to change the label. # semanage fcontext -a -t tftpd_rw_t '/tftpboot(/.*)?' # restorecon -R -v /tftpboot
IMHO this is a bug in the SE Linux configuration. When used to save configs of network devices write access is needed. This is a standard use of TFTP servers.
So you think that we should be insecure by default. Allow untrusted apps to write to the tftpboot directory?
(In reply to comment #3) > So you think that we should be insecure by default. Allow untrusted apps to > write to the tftpboot directory? Well, I agree with both of you. Erik is correct in that, if I install TFTP SERVER then I want it to write data somewhere. This is configured in the xinetd.d config files, and by default it SHOULD be tftpboot, which I think SELINUX should allow by default. If the write was to take place to a DIFFERENT folder, then I accept that it should be deemed unsafe an require SELINUX to approve it. It is my opinion that MANY Fedora users immediately turn off SELINUX or set it to permissive mode because it is simply too much a pain in the ass. I was intending to run my clean Fedora 11 installation with it in ENFORCING mode. But after this error I retreated back to permissive. Incidentally Daniel, the tips you mentioned in comment #1 didn't work for me. - semanage fcontext -a -t tftpd_rw_t '/tftpboot(/.*)?' did not like the parameter tftpd_rw_t. Since the error was blocking tftpd_t I decided to use that type instead. (this is completely guesswork on my part because I do not understand SELINUX well - it seems like waaaay too much to digest at first glance.) semanage accepted these parameters. - restorecon -R -v /tftpboot then gave me an error after running the above, namely: "SELinux denied access requested by restorecon. /tftpboot/eobsst01 may be a mislabeled. /tftpboot/eobsst01 default SELinux type is tftpdir_t, but its current type is tftpd_t. Changing this file back to the default type, may fix your problem." So I re-ran semanage with -t tftpdir_t and restorecon ran happily. Of course, this has solved nothing. I do look forward to you reply, though.
Sorry tftpdir_rw_t # semanage fcontext -a -t tftpdir_rw_t '/tftpboot(/.*)?' In Fedora 12 the setroubleshoot will tell you this # sealert -a /tmp/t 100% donefound 1 alerts in /tmp/t -------------------------------------------------------------------------------- Summary: SELinux is preventing the tftp daemon from modify tftpboot. Detailed Description: [in.tftpd has a permissive type (tftpd_t). This access was not denied.] SELinux prevented the tftp daemon from writing to tftpboot. Usually tftpd is setup only to read content and is not allowed to modify it. If you setup tftpd to modify tftpboot need to change its label. If you did not setup tftp to modify tftpboot, this could signal an intrusion attempt. Allowing Access: If you want to change the file context of tftpboot so that the tftp daemon can modify it, you need to execute it using # semanage fcontext -m tftpdir_rw_t '/tftpboot(/.*)?' # restorecon -R -v /tftpboot Additional Information: Source Context system_u:system_r:tftpd_t:s0-s0:c0.c1023 Target Context system_u:object_r:tftpdir_t:s0 Target Objects tftpboot [ dir ] Source in.tftpd Source Path /usr/sbin/in.tftpd Port <Unknown> Host lvd-pc.localdomain Source RPM Packages tftp-server-0.49-5.fc12 Target RPM Packages Policy RPM selinux-policy-3.6.32-28.fc12 Selinux Enabled True Policy Type targeted MLS Enabled True Enforcing Mode Enforcing Plugin Name tftpd_write_content Host Name localhost.localdomain Platform Linux localhost.localdomain 2.6.31.1-48.fc12.x86_64 #1 SMP Fri Sep 25 16:57:40 EDT 2009 x86_64 x86_64 Alert Count 1 First Seen Wed Jul 15 06:36:01 2009 Last Seen Wed Jul 15 06:36:01 2009 Local ID d53d27de-805e-452e-a202-6d6cc7db8108 Line Numbers 1, 3, 4, 5, 6 Raw Audit Messages node=lvd-pc.localdomain type=AVC msg=audit(1247654161.234:60): avc: denied { write } for pid=6220 comm="in.tftpd" name="tftpboot" dev=dm-0 ino=15007778 scontext=system_u:system_r:tftpd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:tftpdir_t:s0 tclass=dir node=lvd-pc.localdomain type=AVC msg=audit(1247654161.234:60): avc: denied { add_name } for pid=6220 comm="in.tftpd" name="eikest02-confg" scontext=system_u:system_r:tftpd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:tftpdir_t:s0 tclass=dir node=lvd-pc.localdomain type=AVC msg=audit(1247654161.234:60): avc: denied { create } for pid=6220 comm="in.tftpd" name="eikest02-confg" scontext=system_u:system_r:tftpd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:tftpdir_t:s0 tclass=file node=lvd-pc.localdomain type=AVC msg=audit(1247654161.234:60): avc: denied { write } for pid=6220 comm="in.tftpd" name="eikest02-confg" dev=dm-0 ino=15007986 scontext=system_u:system_r:tftpd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:tftpdir_t:s0 tclass=file node=lvd-pc.localdomain type=SYSCALL msg=audit(1247654161.234:60): arch=c000003e syscall=2 success=yes exit=1 a0=608de2 a1=41 a2=1b6 a3=4000 items=0 ppid=6045 pid=6220 auid=4294967295 uid=99 gid=99 euid=99 suid=99 fsuid=99 egid=99 sgid=99 fsgid=99 tty=(none) ses=4294967295 comm="in.tftpd" exe="/usr/sbin/in.tftpd" subj=system_u:system_r:tftpd_t:s0-s0:c0.c1023 key=(null)
Often I hear SELinux is too hard, but and I agree it is more complex then DAC controls but in some ways it is similar. SELinux is just about Labeling and the rules between labels. And I would argue the DAC is also about labeling. In DAC the label on the process is just the Owner of the process. and the label on the files is a combination of the owner, group and the premissions, (ACL just extends this). But in order to get a DAC system to work correctly you have to make sure the label on the file and on the process is correct. The rules governing the interaction between the labels on a DAC system are static. If you examine this further, if you were running tftpd as user tftp and you got a permission denied message, You would have to make sure /tftpboot is owned by tftpboot. You would also need to make sure user tftp can write to directory /tftpboot. SELinux is the similar, you would have to make sure that the label on the process tftpd is correct and the label on the directory is correct. But you also need to understand the rules. This is a short paper I wrote on SELinux trying to explain SELinux in simpler terms. http://people.fedoraproject.org/~dwalsh/SELinux/Presentations/selinux_four_things.pdf SELinux is trying to tell you one of four things. A tool that I often use and setroubleshoot is starting to use is seinfo. If I wanted to see what label to assign to a directory a process running as tftpd_t can write to I can execute: # sesearch --allow -s tftpd_t -c dir -p write Found 5 semantic av rules: allow tftpd_t tftpd_var_run_t : dir { ioctl read write getattr lock add_name remove_name search open } ; allow tftpd_t tftpdir_rw_t : dir { ioctl read write create getattr setattr lock unlink link rename add_name remove_name reparent search rmdir open } ; allow tftpd_t var_run_t : dir { ioctl read write getattr lock add_name remove_name search open } ; allow tftpd_t public_content_rw_t : dir { ioctl read write create getattr setattr lock unlink link rename add_name remove_name reparent search rmdir open } ; allow daemon root_t : dir { ioctl read write getattr lock add_name remove_name search open } ; The human has to step in at this point and figure out the best one to use.
Ahhh, thanks, that worked for me. I will read your paper. I am not against SELINUX, it's just that at present I don't really understand it. The messages in Fedora 12 you quoted above are excellent! They actually give more detail about the WHY it failed and the HOW to fix it. This will go a LONG way to improving the usability and the acceptance of SELINUX. So thanks to all involved in that!
The improved setroubleshoot message is a real improvement. I still think the TFTP server should be allowed to write into its directory by default (and only this directory). This is a special directory for TFTP. Daniel, I just want to state my point of view. If you disagree then so be it. The improved help message is an acceptable compromise for me.
Well, finally I've got TFTP write access working with SELinux in enforcing mode. The target directory seems to have the correct context: # semanage fcontext -a -t tftpdir_rw_t '/var/lib/tftpboot(/.*)?' /usr/sbin/semanage: File context for /var/lib/tftpboot(/.*)? already defined A file created therein (by root, the dir has 0755 permissions, owner root:root) has file context tftpdir_t. If changed to tftpdir_rw_t in.tftpd can write to it: # touch /var/lib/tftpboot/rms.cfg # chmod 666 /var/lib/tftpboot/rms.cfg # ls --context /var/lib/tftpboot/ -rw-rw-rw-. root root unconfined_u:object_r:tftpdir_t:s0 rms.cfg # chcon -t tftpdir_rw_t /var/lib/tftpboot/rms.cfg Not knowing much about SELinux I don't know if this a bug. It is violating the principle of least surprise for people knowing only the traditional TFTP configuration/usage, i.e. without SELinux. The directory /var/lib/tftpboot is intended to be written by in.tftpd. The files to be written to need to be manually created and set to mode 666. The selinuxtroubleshoot output could be enhanced by mentioning 'chcon -t tftpdir_rw_t' for files intended to be written to. IMHO this would help the administrator new to SELinux and keep the spirit of manually allowing TFTP write access only. [Of course directories, file owners and file permissions used by in.tftpd can be changed via commandline option. The description above fits the Fedora 11 default configuration and reflects pre-SELinux best practice.]
Ok I will change the default labeling of /var/lib/tftpboot to /var/lib/tftpboot(/.*)? gen_context(system_u:object_r:tftpdir_rw_t,s0) Fixed in selinux-policy-3.6.32-29.fc12.noarch Miroslav can you make a similar change in F11?
Fixed in selinux-policy-3.6.12-86.fc11
This message is a reminder that Fedora 11 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 11. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '11'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 11's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 11 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping