All of lore.kernel.org
 help / color / mirror / Atom feed
From: Petr Lautrbach <plautrba@redhat.com>
To: Stephen Smalley <sds@tycho.nsa.gov>
Cc: Petr Lautrbach <plautrba@redhat.com>,
	selinux@vger.kernel.org,
	"Christopher J. PeBenito" <pebenito@ieee.org>,
	stephen.smalley.work@gmail.com
Subject: Re: [PATCH v4] libsepol, checkpolicy: remove use of hardcoded security class values
Date: Thu, 12 Mar 2020 07:53:14 +0100	[thread overview]
Message-ID: <pjdimjaawth.fsf@redhat.com> (raw)
In-Reply-To: <431cc5f6-e666-e875-a4fd-4d98b414d82f@tycho.nsa.gov>


Stephen Smalley <sds@tycho.nsa.gov> writes:

> On 1/29/20 7:52 AM, Petr Lautrbach wrote:
>> Stephen Smalley <sds@tycho.nsa.gov> writes:
>> 
>>> On 1/26/20 5:57 AM, Petr Lautrbach wrote:
>>>>
>>>> Stephen Smalley <sds@tycho.nsa.gov> writes:
>>>>
>>>>> libsepol carried its own (outdated) copy of flask.h with the generated
>>>>> security class and initial SID values for use by the policy
>>>>> compiler and the forked copy of the security server code
>>>>> leveraged by tools such as audit2why.  Convert libsepol and
>>>>> checkpolicy entirely to looking up class values from the policy,
>>>>> remove the SECCLASS_* definitions from its flask.h header, and move
>>>>> the header with its remaining initial SID definitions private to
>>>>> libsepol.  While we are here, fix the sepol_compute_sid() logic to
>>>>> properly support features long since added to the policy and kernel,
>>>>> although there are no users of it other than checkpolicy -d (debug)
>>>>> and it is not exported to users of the shared library.  There
>>>>> are still some residual differences between the kernel logic and
>>>>> libsepol.
>>>>>
>>>>> Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov>
>>>>
>>>>
>>>> The only problem I found running tests on this is related to SETools
>>>> https://github.com/SELinuxProject/selinux/pull/200#issuecomment-577745225
>>>>
>>>> Acked-by: Petr Lautrbach <plautrba@redhat.com>
>>>
>>> Thanks.  I guess the question is whether we should wait to merge it until
>>> setools has a corresponding fix ready or go ahead.
>> https://github.com/SELinuxProject/setools/issues/39
>> Lets wait until there's a response from Christopher.
>
> setools issue has been resolved, so this should now be mergeable.

Applied, thanks.


      parent reply	other threads:[~2020-03-12  6:53 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-01-21 18:40 [PATCH v4] libsepol,checkpolicy: remove use of hardcoded security class values Stephen Smalley
2020-01-26 10:57 ` Petr Lautrbach
2020-01-27 13:58   ` [PATCH v4] libsepol, checkpolicy: " Stephen Smalley
2020-01-29 12:52     ` Petr Lautrbach
     [not found]       ` <431cc5f6-e666-e875-a4fd-4d98b414d82f@tycho.nsa.gov>
2020-03-12  6:53         ` Petr Lautrbach [this message]

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=pjdimjaawth.fsf@redhat.com \
    --to=plautrba@redhat.com \
    --cc=pebenito@ieee.org \
    --cc=sds@tycho.nsa.gov \
    --cc=selinux@vger.kernel.org \
    --cc=stephen.smalley.work@gmail.com \
    /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.