All of lore.kernel.org
 help / color / mirror / Atom feed
From: KaiGai Kohei <kaigai@ak.jp.nec.com>
To: Joshua Brindle <jbrindle@tresys.com>
Cc: selinux@tycho.nsa.gov
Subject: hierarchy_check_constraints() needs reworks?
Date: Thu, 24 Jul 2008 14:38:14 +0900	[thread overview]
Message-ID: <48881546.6070903@ak.jp.nec.com> (raw)

I found out that hierarchy_check_constraints() in libsepol
does not work correctly, as follows:

---- example: foo.te ----
module foo 1.0;

require {
        class file { read write getattr setattr ioctl };
};

type src;
type src.child;
type tgt;

allow src       tgt : file { read write };
allow src.child tgt : file { read write getattr setattr };
----------
[root@fedora9 kaigai]# checkmodule -m -M foo.te -o foo.mod
checkmodule:  loading policy configuration from foo.te
checkmodule:  policy configuration loaded
checkmodule:  writing binary representation (version 8) to foo.mod
[root@fedora9 kaigai]# /usr/sbin/semodule -i foo.pp
[root@fedora9 kaigai]#

The "foo.te" can make a hierarchy constraint violation, but we got
no assertion in this case.

I inject several printf()s to show internal state, and it shows me
the given p->te_avtab is empty, so no checks are applied. :-(
Now, I'm tracing it more.


In addition, I found two more potential matter in this code.

The first one is lack of checks for permissions via attribute.
When a child domain has an attribute which does not applied to
the parent one, the child can have wider permissions that its
parent.
I think any attribute attached to child domain also have to be
attached to the parent domain.
(I guess it derived from legacy attribute implementation.)

The later one is dependencies to the state of boolean.
Hierarchy constraint allows a child domain to have permissions
which are enabled for the parent, only if specific boolean is
turned on. It potentially makes a situation that child domain
has wider permissions.
I think it is difficult to check in the policy toolchain, so
checks on an avc entry creation is better way.

Any comment?

Thanks,
-- 
OSS Platform Development Division, NEC
KaiGai Kohei <kaigai@ak.jp.nec.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:[~2008-07-24  5:38 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-07-24  5:38 KaiGai Kohei [this message]
2008-07-24 11:24 ` hierarchy_check_constraints() needs reworks? Stephen Smalley
2008-07-24 18:22   ` Mapping Linux GROUP to an SELinux user ? Hasan Rezaul-CHR010
2008-07-25  1:05     ` Stephen Smalley
2008-07-28 23:41       ` Karl MacMillan
2008-07-29 13:37         ` Daniel J Walsh
2008-07-25  0:39   ` hierarchy_check_constraints() needs reworks? KaiGai Kohei
2008-07-24 14:40 ` Joshua Brindle
2008-07-25  2:31   ` KaiGai Kohei

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=48881546.6070903@ak.jp.nec.com \
    --to=kaigai@ak.jp.nec.com \
    --cc=jbrindle@tresys.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.