selinux.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Richard Haines <richard_c_haines@btinternet.com>
To: Stephen Smalley <sds@tycho.nsa.gov>, selinux@vger.kernel.org
Cc: omosnace@redhat.com
Subject: Re: [PATCH V2 1/1] selinux-testsuite: Add filesystem tests
Date: Sun, 12 Jan 2020 16:04:00 +0000	[thread overview]
Message-ID: <f863a91987c1926a4351f3edf968c9003197fead.camel@btinternet.com> (raw)
In-Reply-To: <c2cc9f48-4dd3-cdf4-8c4e-3575ffc05aaf@tycho.nsa.gov>

On Fri, 2020-01-10 at 13:18 -0500, Stephen Smalley wrote:
> On 1/10/20 1:09 PM, Richard Haines wrote:
> > On Thu, 2020-01-09 at 12:19 -0500, Stephen Smalley wrote:
> > > On 1/9/20 10:07 AM, Richard Haines wrote:
> > > > Test filesystem permissions and setfscreatecon(3).
> > > > 
> > > >   From kernels 5.5 filesystem { watch } is also tested.
> > > > 
> > > > Signed-off-by: Richard Haines <richard_c_haines@btinternet.com>
> > > > ---
> > > > diff --git a/policy/test_filesystem.te
> > > > b/policy/test_filesystem.te
> > > > new file mode 100644
> > > > index 0000000..2eee1fc
> > > > --- /dev/null
> > > > +++ b/policy/test_filesystem.te
> > > > @@ -0,0 +1,324 @@
> > > > +#
> > > > +######### Test filesystem permissions policy module ##########
> > > > +#
> > > > +attribute filesystemdomain;
> > > > +
> > > > +#################### Create a test file context
> > > > ######################
> > > > +type test_filesystem_filecon_t;
> > > > +unconfined_runs_test(test_filesystem_filecon_t)
> > > > +
> > > > +################# Test all functions
> > > > ##########################
> > > > +type test_filesystem_t;
> > > > +domain_type(test_filesystem_t)
> > > > +unconfined_runs_test(test_filesystem_t)
> > > > +typeattribute test_filesystem_t testdomain;
> > > > +typeattribute test_filesystem_t filesystemdomain;
> > > > +
> > > > +allow test_filesystem_t self:capability { sys_admin };
> > > > +allow test_filesystem_t self:filesystem { mount remount
> > > > quotamod
> > > > relabelfrom relabelto unmount quotaget };
> > > > +allow test_filesystem_t self:dir { mounton add_name write };
> > > > +allow test_filesystem_t test_file_t:dir { mounton write
> > > > remove_name rmdir };
> > > > +# Create test file
> > > > +allow test_filesystem_t self:dir { add_name write };
> > > > +allow test_filesystem_t self:file { create relabelfrom
> > > > relabelto
> > > > };
> > > > +
> > > > +fs_mount_all_fs(test_filesystem_t)
> > > > +fs_remount_all_fs(test_filesystem_t)
> > > > +fs_unmount_all_fs(test_filesystem_t)
> > > > +fs_relabelfrom_all_fs(test_filesystem_t)
> > > > +fs_get_xattr_fs_quotas(test_filesystem_t)
> > > > +files_search_all(test_filesystem_t)
> > > > +# Required for mount opts
> > > > "rootcontext=system_u:object_r:test_filesystem_t:s0";
> > > > +fs_associate(test_filesystem_t)
> > > > +fs_getattr_xattr_fs(test_filesystem_t)
> > > > +
> > > > +# For running quotacheck(8)
> > > > +files_type(test_filesystem_t)
> > > > +# Update quotas
> > > > +fs_set_all_quotas(test_filesystem_t)
> > > > +allow test_filesystem_t self:file { quotaon };
> > > > +# Create test file and change context:
> > > > +fs_associate(test_filesystem_filecon_t)
> > > > +allow test_filesystem_t test_filesystem_filecon_t:file { open
> > > > read
> > > > getattr relabelto write };
> > > > +dontaudit test_filesystem_t kernel_t:process { setsched };
> > > 
> > > Why do you need these dontaudit statements?  It seems like a
> > > kernel
> > > bug
> > > if something is triggering a setsched permission check on the
> > > kernel_t
> > > domain?  Something the kernel module is doing during
> > > initialization?
> > > 
> > 
> > I've tracked this down to them all being called from block/ioprio.c
> > with: security_task_setioprio(task, ioprio) ->
> > selinux_task_setioprio
> > 
> > Why the SECCLASS_PROCESS, PROCESS__SETSCHED I've no idea. The
> > following
> > also use SET/GETSCHED permission:
> > 
> > selinux_task_getioprio, selinux_task_setnice,
> > selinux_task_movememory
> 
> The confusing bit is that it is between test_filesystem_t and
> kernel_t. 
> If the process was setting its own ioprio, then I'd expect to see
> the 
> denial between test_filesystem_t and test_filesystem_t aka self.  If
> the 
> process inserted a kernel module and the module initializer spawned
> a 
> kernel thread that set its ioprio, I would expect it to be kernel_t
> to 
> kernel_t.

Some more info on who calls set_task_ioprio:

fs/ext4/super.c calls 'set_task_ioprio' in two places using:
    set_task_ioprio(sbi->s_journal->j_task, journal_ioprio);
The return codes are not checked. This code was added 11 years ago.

fs/btrfs/reada.c also calls 'set_task_ioprio' in two places using:
    set_task_ioprio(current, BTRFS_IOPRIO_READA);
The return codes are not checked.

As can be seen the ext4 module does not use 'current'. I have patched
kernel 5.5-rc5 to use 'current' and it now works as you expected. Also
the kernel_t:process { setsched } rules can be removed.
As the problem will exist for some time, I've added to the test policy:
    kernel_dontaudit_setsched(filesystemdomain)

It appears that most of the refpolicy modules do the same.



  reply	other threads:[~2020-01-12 16:04 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-01-09 15:07 [PATCH V2 0/1] selinux-testsuite: Add filesystem tests Richard Haines
2020-01-09 15:07 ` [PATCH V2 1/1] " Richard Haines
2020-01-09 17:14   ` Stephen Smalley
2020-01-09 17:40     ` Richard Haines
2020-01-09 17:19   ` Stephen Smalley
2020-01-09 17:45     ` Richard Haines
2020-01-10 18:09     ` Richard Haines
2020-01-10 18:18       ` Stephen Smalley
2020-01-12 16:04         ` Richard Haines [this message]
2020-01-13 13:52           ` Stephen Smalley
2020-01-13 14:07             ` Stephen Smalley
2020-01-13 18:00               ` Richard Haines
2020-01-13 18:54                 ` Stephen Smalley
2020-01-09 17:46   ` Stephen Smalley
2020-01-09 17:51     ` Richard Haines
2020-01-09 18:04 ` [PATCH V2 0/1] " Stephen Smalley
2020-01-09 20:36   ` Richard Haines
2020-01-09 21:01     ` Ondrej Mosnacek
2020-01-10 14:28       ` Richard Haines

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=f863a91987c1926a4351f3edf968c9003197fead.camel@btinternet.com \
    --to=richard_c_haines@btinternet.com \
    --cc=omosnace@redhat.com \
    --cc=sds@tycho.nsa.gov \
    --cc=selinux@vger.kernel.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).