All of lore.kernel.org
 help / color / mirror / Atom feed
From: Michal Svoboda <michal.svoboda@agents.felk.cvut.cz>
To: selinux@tycho.nsa.gov
Subject: Re: MCS and default labels
Date: Mon, 14 Sep 2009 10:19:10 +0200	[thread overview]
Message-ID: <20090914081910.GL24297@myhost.felk.cvut.cz> (raw)
In-Reply-To: <1252498660.13634.618.camel@moss-pluto.epoch.ncsc.mil>

[-- Attachment #1: Type: text/plain, Size: 1093 bytes --]

Stephen Smalley wrote:
> The kernel MLS logic lives in security/selinux/ss/mls.c.  Determining
> the MLS level of a new subject or object is handled by
> mls_compute_sid().  Any change would have to support either model
> (inherit from source context or inherit from target context), so
> logically it would be policy-driven.  Which likely means an extension to
> the policy language and compiler.  Not an entirely trivial undertaking.

I have looked at the source code and it seems that in the said function
mls_compute_sid(), under the "case AVTAB_CHANGE:" and in the "else" path
(tclass != SECCLASS_PROCESS) the statement

mls_context_cpy_low(newcontext, scontext)

would need to be changed to

mls_context_cpy(newcontext, tcontext).

To support the original behavior, I would add a 1/0 readable/writable
file to selinuxfs, say "mls_defcontext_inherit" by mimicking the
behavior of the "enforce" file and its associated r/w functions. It
seems to me that this would suffice enough and it would avoid the need
to modify the policy language.

Would this change be acceptable?

Michal Svoboda

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

  parent reply	other threads:[~2009-09-14  8:19 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-09-08  5:58 MCS and default labels Michal Svoboda
2009-09-08 15:35 ` Stephen Smalley
2009-09-08 16:36   ` Michal Svoboda
2009-09-08 17:10     ` Stephen Smalley
2009-09-09 10:06       ` Michal Svoboda
2009-09-09 12:17         ` Stephen Smalley
2009-09-09 13:19           ` Michal Svoboda
2009-09-09 13:34             ` Stephen Smalley
2009-09-09 13:59               ` Michal Svoboda
2009-09-09 14:34                 ` Stephen Smalley
2009-09-14  8:19           ` Michal Svoboda [this message]
2009-09-14 12:20             ` Stephen Smalley
2009-09-14 13:00               ` Stephen Smalley
2009-09-15  6:32               ` Michal Svoboda
2009-09-15 11:16                 ` Stephen Smalley
2009-09-27  7:34           ` Russell Coker
2009-09-28 13:37             ` Stephen Smalley
2009-09-28 20:57               ` Russell Coker
2009-09-28 23:22               ` Kyle Moffett
2009-09-29 12:21                 ` Stephen Smalley
2009-09-29 13:54                   ` Kyle Moffett
2009-09-29 20:54                     ` Paul Moore
2009-09-30  3:51                       ` Kyle Moffett
2009-09-30 13:19                         ` Paul Moore
2009-09-30 13:49                           ` Kyle Moffett
2009-09-30 14:20                             ` Paul Moore

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=20090914081910.GL24297@myhost.felk.cvut.cz \
    --to=michal.svoboda@agents.felk.cvut.cz \
    --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.