All of lore.kernel.org
 help / color / mirror / Atom feed
From: Scott Radvan <sradvan@redhat.com>
To: SE Linux <selinux@tycho.nsa.gov>, fedora-selinux-list@redhat.com
Subject: Trying to cause a denial with rsync and SELinux
Date: Mon, 20 Jul 2009 11:53:38 +1000	[thread overview]
Message-ID: <20090720115338.247ede30@redhat.com> (raw)

Hello all,


I'm having troubles invoking _any_ denial whatsoever for rsync related
tasks, in order for me to demonstrate in my book how to then work
around it. 

I've made a custom init script for rsync as there is no existing one in
Fedora 11, so I labeled it initrc_exec_t so that the rsync daemon
transitions to rsync_t:

# ps -eZ | grep rsync
unconfined_u:system_r:rsync_t:s0  326 ?        00:00:00 rsync

According to the information I have, now that it's running as rsync_t,
the following Booleans should have an effect:

allow_rsync_anon_write

	No mattter the state of this Boolean, I can still write to 
	public_content_rw_t files, locally or over the LAN.

rsync_client

	I have very little information on this Boolean and what it
	actually implies, what it requires in terms of labels, etc. but
	no matter its state, rsync operates normally as a client
	reading and writing to a daemonized process on another machine.

rsync_export_all_ro

	Perhaps I'm misinterpreting this one as well, but no matter its
	state, I can read _and_ write the test files in the directory
	specified by the rsync daemon, locally and over the network.

Really, I'm probably misinterpreting these Booleans and their actual
implications, or doing something completely wrong.

I simply need a way that I can get SELinux to give me a denial related
to rsync (running as a daemon) which I can then document and demonstrate
the work-around for. My problem remains that everything works too _well_
and SELinux doesn't seem to be denying any of the access or transfers
I'm performing, whatever the state of these Booleans, based on my
limited understanding of them.

Does anyone have a better understanding of these particular Booleans,
what they actually imply, what labels the files need in order to be
affected by them, any other condition they require to enforce upon the
system...and mainly how I can intentionally invoke a denial based on
one of them?


Thanks in advance,


-- 
Scott Radvan
Content Author, Platform (Installation and Deployment)
Red Hat Asia Pacific (Brisbane) http://www.apac.redhat.com

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

                 reply	other threads:[~2009-07-20  1:53 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20090720115338.247ede30@redhat.com \
    --to=sradvan@redhat.com \
    --cc=fedora-selinux-list@redhat.com \
    --cc=selinux@tycho.nsa.gov \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.