rsync -rlptgoH --delete billlaptop::importantStuff /snapshot/importantStuff
and 
/usr/sbin/setsebool rsync_export_all_ro off
should have shown up as separate lines above.

*** Bug 543107 has been marked as a duplicate of this bug. ***

Can we start over.  Remove the setting of the booleans and lets discuss what
you want to set up.

Are you setting up an rsync server where the server will write content to
/snapshot?

Have you read man "rsync_selinux"?

Haven't read man "rsync_selinux" as I didn't know it existed. I'll take a look at it.

From the beginning.

I've had a script (snapshotbackup - about 500 lines) I wrote years ago that takes snapshots of certain areas of a drive periodically according to a crontab setting. That script boils down to just a few simple commands, and rsync is the main engine. This script has worked for me and dozens of clients for years. 

My use of it is to snapshot /root, /usr/local/sbin, /etc and a few other directories to a spot on the same machines fixed disk at /snapshot. I run the rsyncd daemon via xinetd and the rsyncd.conf is below:
==============================
[importantStuff]
   comment=This is a master backup of this machine
   path=/
   read only=true
   ignore nonreadable=true
   list=false
   uid=root
   gid=root
   hosts allow=multimedia \ 
               multimedia.private.ycc \
               billlaptop \
               billlaptop.private.ycc \
               localhost
   filter=- / - *.tmp - *~ - *.bak \
          + /root/ - /root/.icedteaplugin/ + /root/*** \
          + /usr/ + /usr/local/ + /usr/local/sbin/*** \
          + /var/ + /var/cache/ + /var/cache/yum/*** \
          + /etc/ + /etc/shorewall/*** - /etc/*/ + /etc/* \
          - *
#   pre-xfer exec=/usr/sbin/setsebool rsync_export_all_ro on
#   post-xfer exec=/usr/sbin/setsebool rsync_export_all_ro off
=============================

The script boils down to these typical statements:
mkdir -p /snapshot/billlaptop/Wed.091202_1802
cp -lRP --preserve=all /snapshot/billlaptop/Wed.091202/importantStuff /snapshot/billlaptop/Wed.091202_1802/importantStuff
rsync -rlptgoH --delete billlaptop::importantStuff /snapshot/billlaptop/Wed.091202_1802/importantStuff


I installed F12 on my laptop and discovered the script produced 35 selinux "incidents" via sealert every time it ran. Of the 35, 70% were real denials with the rest nuisance messages about what it didn't particularly like but let slide anyway. All the incidents came from rsync. The number of incidents is related to the number of directories I asked it to process. If I change what I ask it to do, the number of incidents changes too.
Samples:
SELinux is preventing /usr/bin/rsync access to a leaked /bin/sh file descriptor.
SELinux is preventing /usr/bin/rsync "execute" access on /bin/bash.
SELinux is preventing /usr/bin/rsync "read open" access to /bin/bash.
SELinux is preventing /usr/bin/rsync "execute_no_trans" access on /bin/bash.
SELinux is preventing /bin/bash "getattr" access to /bin/bash.
SELinux is preventing /bin/bash "execute" access on /usr/sbin/setsebool.
SELinux is preventing /bin/bash "getattr" access to /usr/sbin/setsebool.
SELinux is preventing /bin/bash "read open" access to /usr/sbin/setsebool.
SELinux is preventing /bin/bash "read" access to /usr/sbin/setsebool.
SELinux is preventing /bin/bash "execute_no_trans" access on
/usr/sbin/setsebool.

Long story short, selinux broke my script. OK - I'll cooperate and write some rules to make the script and selinux peacefully coexist.  

For every selinux failure in sealert I'd save the alert to the clipboard and then paste from the clipboard into a file via an editor, saving the file as /tmp/avc# where # was an incremental number. After each new file was created in /tmp, I did the following:
cat /tmp/avc* >/tmp/AVC 
audit2allow -M rsyncForsnapshotbackup </tmp/AVC 
semodule -i rsyncForsnapshotbackup.pp 
mv rsyncForsnapshotbackup.* /root 

This would accumulate all the alerts up to that point into /tmp/AVC and then build one .te & .pp file to be applied to the system. Then another snapshotbackup would produce another sealert and I'd repeat the process till all the alerts were gone, but one. It seams that no matter what, I couldn't get rid of a bogus alert saying that the context of / was something other than what it really was. It took 8 iterations to accumulate all the failures.

The final rsyncForsnapshotbackup.te is below:
==========================
module rsyncForsnapshotbackup 1.0;

require {
	type setsebool_exec_t;
	type bin_t;
	type rsync_t;
	type shell_exec_t;
	class lnk_file read;
	class file { execute read execute_no_trans getattr open };
}

#============= rsync_t ==============
allow rsync_t bin_t:lnk_file read;
allow rsync_t setsebool_exec_t:file { read execute open getattr execute_no_trans };
allow rsync_t shell_exec_t:file { read execute open getattr execute_no_trans };
===========================

Immediately before the rsync execution statement I had to put:
/usr/sbin/setsebool rsync_export_all_ro on
and immediately after I put:
/usr/sbin/setsebool rsync_export_all_ro off

Then I tried to put those 2 statements into the rsyncd.conf file as pre-xfer and post-xfer statements. That would cause rsync to fail as reported in a bugzilla, so for now the script executes those statements explicitly instead of the more appropriate inclusion in the rsyncd.conf file to hide this ugly detail.

Right now, my script works as it did before. I am executing setsebool statements I really don't understand, have added rules to the system I also don't comprehend and am still getting one nuisance message about / having the wrong context which I also bugzilla'd. 

Note that what I bugzill'd was a failure in rsync not handling the pre-xfer statement in the config file, and the bogus sealert for the context on / (The root). I haven't really complained about selinux per se.

Selinux got in my way, and I circumvented it to get it out of my hair, but I'm not proud of what I've had to do because I don't understand selinux and can't seem to find any readable documentation to get me up to speed. I have tried on more than one occasion. I've got over 30 years as a professional programmer and can't penetrate the jargon and artificial language invented to describe it. 

As it is, selinux is a PITA as I have to live with it but can't communicate with it properly because I don't speak its language. If there's a complaint in there somewhere, its that the documentation is very very poor. I think the folks writing the docs are so into it and so comfortable with it that they can't remember what it was like not knowing it and therefore can't come down to a level suitable for describing it to an selinux novice.

THe problem is you went off track right from the beginning when just setting the label on the /snapshot directory would have worked, you got lost in SELinux configuration hell.

I wrote a paper on the 4 things that SELinux is trying to tell you and most of the time it is your labeling is screwed up.


http://people.fedoraproject.org/~dwalsh/SELinux/Presentations/selinux_four_things.pdf

You needed to set  a label for the directory you wanted the confined application to write to.  /snapshot.

The domain that needed to write there is rsync_t.

There is a tool sesearch that allows you to search for the types that rsync can write to.



# sesearch -A -s rsync_t -c file -p write -C
Found 6 semantic av rules:
   allow rsync_t rsync_tmp_t : file { ioctl read write create getattr setattr lock append unlink link rename open } ; 
   allow rsync_t rsync_var_run_t : file { ioctl read write create getattr setattr lock append unlink link rename open } ; 
   allow rsync_t rsync_log_t : file { ioctl read write create getattr setattr lock append unlink link rename open } ; 
   allow rsync_t rsync_t : file { ioctl read write getattr lock append open } ; 
DT allow rsync_t public_content_rw_t : file { ioctl read write create getattr setattr lock append unlink link rename open } ; [ allow_rsync_anon_write ]
DT allow rsync_t rsync_data_t : file { ioctl read write create getattr setattr lock append unlink link rename open } ; [ rsync_client ]

This says rsync_t domain can write to files labeled rsync_tmp_t, rsync_var_run_t, rsync_log_t. 

If you turn on the boolean allow_rsync_anon_write  it can write to public_content_rw_t.

If you turn on the boolean rsync_client  it can write to rsync_data_t, (which I think is a bug), it should be able to write here no matter what.

Setting the label on /snapshot to any of these would have allowed your scripts to work.  

/snapshot will get the default label default_t

To change the labeling to rsync_data_t permanently, you need to execute

# semanage fcontext -a -t rsync_data_t '/snapshot(/.*)?'
# restorecon -R -v /snapshot

Because of the bug in policy you need to turn on the boolean permanantly.  Note you only need to do this once.

# setsebool -P rsync_client 1


I think that would solve your problem.  What I am interested in, was what was the first setroubleshoot message that you got, did it tell you anything like the above?

Daniel:

After doing a little digging I just realized who you are. You're the head selinux person. Perfect.

I read your last post and tried to comprehend it but can't. Therein lies the problem. You are offering me a fish, and I'm grateful, but what I need to be able to do is fish for myself. I want to understand selinux sufficiently to diagnose an issue correctly and not go off in a wrong direction as you indicated I did. I'd like to be able to understand what you're saying, not just key in some commands like a robot to solve this issue.

If I segregate Linux users into just 2 camps, they would be those that just want Linux to work and don't care how the magic happens, and then there are those that want to understand in detail how the whole thing hangs together. I'm in the latter camp.

Can you supply me with a reading list to get me up to speed on selinux? I promise to read it and I expect to be able afterwards to converse with you intelligently about what I learned. If after consuming your list I still can't do that I'll let you know, and I would consider that a failure of the documentation, so this is an opportunity to test the documentations usefulness.

Right now I am ignorant of selinux, but I'm not stupid. Given access to the right information, I'll comprehend it.

The selinux wiki on Fedoras site is not what I'm looking for as I doubt anyone can learn about selinux from there. References to FC4 and FC5 give me pause. If there's a book you would recommend that I can purchase from Amazon, I'll do it, but as I now live outside the US, just getting a book will take a month. If there are web sites, just list them, but please don't send me to sites with outdated information or information that isn't true about the selinux implementation in Fedora 12.

To answer your last question, I can't remember and now have no logs of the setroubleshoot messages that led me here. I plan on installing F12 on another box next week and will then have an opportunity to recreate the situation and will capture the sequence of events and all logs.

http://people.fedoraproject.org/~dwalsh/SELinux/Presentations/selinux_four_things.pdf

http://docs.fedoraproject.org/selinux-user-guide/f10/en-US/

http://docs.fedoraproject.org/selinux-managing-confined-services-guide/en-US/F11/html/

http://danwalsh.livejournal.com/

http://www.amazon.com/SELinux-Example-Using-Security-Enhanced/dp/0131963694

Daniel:

I've been away for a while over the holidays, but I started your reading list.

I implemented your suggestions :
root@billlaptop ~# semanage fcontext -a -t rsync_data_t '/snapshot(/.*)?'
root@billlaptop ~# restorecon -R -v /snapshot
root@billlaptop ~# setsebool -P rsync_client 1

and came up with another permissions issue:

rsync: readlink_stat("/root/.config/google-chrome/SingletonSocket" (in importantStuff)) failed: Permission denied (13)
IO error encountered -- skipping file deletion
rsync error: some files/attrs were not transferred (see previous errors) (code 23) at main.c(1505) [generator=3.0.6]
   rsync failed from:bakery::importantStuff to:/snapshot/bakery/Tue.100112/importantStuff

This execution runs via the rsync daemon (config listed in this thread) by using the following syntax:

root@billlaptop ~# rsync -rlptgoH --delete billlaptop::importantStuff /snapshot/billlaptop/Tue.100112/importantStuff

When I run a plain vanilla 
root@billlaptop ~# mkdir /tmp/trash;rsync -rlptgoH /root/.config /tmp/trash
it works but says its skipping the offending file. Not a problem!

That file is some left over rubbish from a Google Chrome execution:
root@billlaptop ~# ll /root/.config/google-chrome/SingletonSocket
srwxr-xr-x. 1 unconfined_u:object_r:admin_home_t:s0 root root 0 2010-01-12 08:35 /root/.config/google-chrome/SingletonSocket

It appears that only when I try to execute the rsync via the daemon does the error occur. So, is this an selinux permissions issue or some real bug with the rsync daemon?

Probably selinux.  

What OS?  Any avc message in the /var/log/audit/audit.log?

rpm -q selinux-policy-targeted

F12 fully patched.

type=AVC msg=audit(1263311057.846:57): avc:  denied  { getattr } for  pid=22134 comm="rsync" path="/root/.config/google-chrome/SingletonSocket" dev=sda3 ino=3558392 scontext=system_u:system_r:rsync_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:admin_home_t:s0 tclass=sock_file
type=SYSCALL msg=audit(1263311057.846:57): arch=c000003e syscall=6 success=no exit=-13 a0=7fff077d2500 a1=7fff077d1470 a2=7fff077d1470 a3=0 items=0 ppid=1583 pid=22134 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="rsync" exe="/usr/bin/rsync" subj=system_u:system_r:rsync_t:s0-s0:c0.c1023 key=(null)

root@billlaptop ~# rpm -q selinux-policy-targeted
selinux-policy-targeted-3.6.32-66.fc12.noarch

SELinux does not support running X apps as root.

*** This bug has been marked as a duplicate of bug 543970 ***

Why not run X apps as root? 

Please don't mention the word security as the whole machine is mine, and I should be able to do with it what I please. If I crater it do to poor judgement - so be it.

There's a trend happening here that makes Linux look more and more like Windows every day. 

Not good.

I guess I'll really have to get into selinux to undo the damage done purposefully in the name of security. Thanks for the motivation.

If you want to run X as root then you need to either disable SELinux or run it in permissive mode.   Trying to write policy that confines X Applications and handling labeling on /root becomes impossible.  

Running X Apps as root (administrator) is what causes lots of Windows problems, in the first place.

But if you want to run it, then go ahead.

I've run X as root since F11. I have no problems running anything in X proper. Its only when I hit a command line and want to run a script do things go a bit berserk at times.

I suspect that in the not too distant future disabling selinux won't be an option as it will be mandated by gov't (check its pedigree) or it will simply be decided that supporting both an selinux and non selix environment isn't worth the headache and maintenance effort. So, I suspect your suggestion to cripple selinux has a short shelf life.

If actual X applications have problems with selinux, running as root or a mere mortal, then they simply need to get fixed. End of story. Anything else is simply unacceptable.

I think you also need to take off your tech hat and put on one borrowed from marketing. The idea is to make Linux an alternative to other platforms, specifically Windows, and the other "competitors" like Mac's O/S, etc. The idea of hardening a platform is great, but you can't make it so onerous to run it that the other more familiar platform looks better. Linux has to be the best at security AND usability to compete.

IMHO you've got the cart before the horse. You're allowing a technical challenge - to write the rules to control a root X session properly - to say you won't do it. If I were in marketing, I'd be pounding on management to make it happen whatever it takes. Not doing it will further limit Linux's acceptance. No one wants that except Microsoft.

My 2 cents.

BTW - I spent decades as a software developer and then technical product manager in the mainframe world in Texas. I ended my mainframe days in marketing and sales and I pushed hard to make our products the best in class regardless of the technical challenges. No one even tried to pull the wool over my eyes as they knew I knew technically at least as much as they did.

You guys need an internal end users advocate to provide direction. All tech and no marketing savvy doesn't work. Look at Linux's acceptance rate on corporate desktops for proof.