From: Stephen Smalley <sds@tycho.nsa.gov>
To: James Carter <jwcart2@tycho.nsa.gov>, selinux@tycho.nsa.gov
Subject: Re: [PATCH 02/10 v2] libsepol: Treat types like an attribute in the attr_type_map.
Date: Thu, 18 Jun 2015 16:21:52 -0400 [thread overview]
Message-ID: <55832860.5050800@tycho.nsa.gov> (raw)
In-Reply-To: <55832738.60606@tycho.nsa.gov>
On 06/18/2015 04:16 PM, James Carter wrote:
> On 06/18/2015 09:41 AM, Stephen Smalley wrote:
>> Can you provide an example of the difference it makes?
>>
>
> I'll add something like the following.
>
>
> This allows the following statement:
>
> ebitmap_and(&m, &p->attr_type_map[src-1], &p->attr_type_map[tgt-1]);
>
>
> which would have previously been written as:
>
> if (p->type_val_to_struct[src-1]->flavor == TYPE_ATTRIB &&
> p->type_val_to_struct[tgt-1]->flavor == TYPE_ATTRIB) {
> ebitmap_and(&m, &p->attr_type_map[src-1], &p->attr_type_map[tgt-1]);
> } else if (p->type_val_to_struct[k->source_type - 1]->flavor ==
> TYPE_ATTRIB) {
> if (ebitmap_get_bit(&p->attr_type_map[src-1], tgt-1)) {
> ebitmap_set_bit(&m, tgt-1, 1);
> }
> } else if (p->type_val_to_struct[tgt-1]->flavor == TYPE_ATTRIB) {
> if (ebitmap_get_bit(&p->attr_type_map[tgt-1], src-1)) {
> ebitmap_set_bit(&m, src-1, 1);
> }
> } else {
> if (src == tgt) {
> ebitmap_set_bit(&m, src-1, 1);
> }
> }
Oh, you don't have to be that specific. Could just note that this
simplified the implementation of neverallow checking in assertion.c or
something.
>> I was wondering though if we are being inconsistent with type_attr_map.
>> We do set the type itself here upon policydb_read() of an existing
>> kernel policy, but do we do it when first generating the type_attr_map
>> by libsepol?
>>
>>
>
> I only see the type_attr_map being generated in policydb_read for a
> kernel policy and when expand_module() is called. This surprised me and
> made me think that there must be a better place to generate these
> mappings, but I can't think of a better place. Can you?
No, I think it makes sense to generate it in the expand.c code (when
generating the kernel policy from modules) and in policydb_read (when
reading a kernel policy from a file/image). But my question is whether
we are consistently setting the type itself in both places. You did
that for attr_type_map, but are we doing it for type_attr_map? And if
not, why not?
next prev parent reply other threads:[~2015-06-18 20:21 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-06-17 19:58 [PATCH 00/10 v2] Improve libsepol and CIL neverallow and bounds checking James Carter
2015-06-17 19:58 ` [PATCH 01/10 v2] libsepol: Add new ebitmap function named ebitmap_match_any() James Carter
2015-06-18 13:23 ` Stephen Smalley
2015-06-17 19:58 ` [PATCH 02/10 v2] libsepol: Treat types like an attribute in the attr_type_map James Carter
2015-06-18 13:41 ` Stephen Smalley
2015-06-18 13:52 ` Stephen Smalley
2015-06-18 20:16 ` James Carter
2015-06-18 20:21 ` Stephen Smalley [this message]
2015-06-18 20:23 ` Stephen Smalley
2015-06-17 19:58 ` [PATCH 03/10 v2] libsepol: Refactored neverallow checking James Carter
2015-06-17 19:58 ` [PATCH 04/10 v2] libsepol: Refactored bounds (hierarchy) checking code James Carter
2015-06-18 13:56 ` Stephen Smalley
2015-06-18 20:26 ` James Carter
2015-06-18 20:29 ` Stephen Smalley
2015-06-18 20:35 ` James Carter
2015-06-17 19:58 ` [PATCH 05/10 v2] libsepol/cil: Add function to search the CIL AST for an AV rule James Carter
2015-06-17 19:58 ` [PATCH 06/10 v2] libsepol/cil: Refactored CIL neverallow checking and reporting James Carter
2015-06-17 19:58 ` [PATCH 07/10 v2] libsepol/cil: Track number of classes and number of types and attributes James Carter
2015-06-17 19:58 ` [PATCH 08/10 v2] libsepol/cil: Add CIL bounds checking and reporting James Carter
2015-06-17 19:58 ` [PATCH 09/10 v2] secilc: Add a CIL policy file to test neverallow checking James Carter
2015-06-17 19:58 ` [PATCH 10/10 v2] secilc: Add a CIL policy file to test bounds checking James Carter
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=55832860.5050800@tycho.nsa.gov \
--to=sds@tycho.nsa.gov \
--cc=jwcart2@tycho.nsa.gov \
--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.