All of lore.kernel.org
 help / color / mirror / Atom feed
From: Petr Lautrbach <plautrba@redhat.com>
To: Ondrej Mosnacek <omosnace@redhat.com>, James Carter <jwcart2@gmail.com>
Cc: SElinux list <selinux@vger.kernel.org>
Subject: Re: [RFC PATCH userspace 2/5] semodule,libsemanage: move module hashing into libsemanage
Date: Tue, 25 Jan 2022 16:17:58 +0100	[thread overview]
Message-ID: <874k5ru9nd.fsf@redhat.com> (raw)
In-Reply-To: <CAFqZXNsw_i_rarut8kciLVKJiOM1e4e6cizpVk8bZSTZEjgdiw@mail.gmail.com>

Ondrej Mosnacek <omosnace@redhat.com> writes:

> On Thu, Jan 20, 2022 at 10:52 PM James Carter <jwcart2@gmail.com> wrote:
>> On Thu, Jan 13, 2022 at 6:36 PM Ondrej Mosnacek <omosnace@redhat.com> wrote:
>> >
>> > The main goal of this move is to have the SHA-256 implementation under
>> > libsemanage, since upcoming patches will make use of SHA-256 for a
>> > different (but similar) purpose in libsemanage. Having the hashing code
>> > in libsemanage will reduce code duplication and allow for easier hash
>> > algorithm upgrade in the future.
>> >
>> > Note that libselinux currently also contains a hash function
>> > implementation (for yet another different purpose). This patch doesn't
>> > make any effort to address that duplicity yet.
>> >
>> > The changes here are only refactoring, no functional change is done
>> > here. A new libsemanage API function semanage_module_compute_checksum()
>> > is provided and semodule is made to use it for implementing its
>> > hash_module_data() function.
>> >
>> > Note that the API function also returns a string representation of the
>> > hash algorithm used, which is currently unused by semodule. The intent
>> > is to avoid ambiguity and potential collisions when the algorithm is
>> > potentially changed in the future. I could add the hash algorithm to the
>> > semodule output, but doing so might break tools parsing the exisiting
>> > format. (RFC: Should I change it anyway?)
>> >
>>
>> So that it would be a part of the hash string returned by
>> hash_module_data() in semodule.c?
>
> Yes. I imagine something like
> "sha256:0123456789abcfdef0123456789abcfdef0123456789abcfdef0123456789abcfdef"
> as used in the checksum file for the module changes detection.
>
>> I would want to hear from people who use the hashes before I would
>> want to change anything.
>
> Yep, I guess this is mainly a question for Petr, who was in contact
> with the team requesting this feature. Petr?
>

Given that it's used as a string and just compared whether it's same, I
guess it would be ok to change it. ssh uses a similar format for
fingerprint - SHA256:vEJndgoJKp27dZKD/R1i34ViA6Fn3VfOB6UjmWIQD5g - so it
makes sense.

To make it simple for users, it would be great if `semodule` provides
posibility to show a checksum also for module files, e.g. users would just
compare output of `semodule --checksum --show ./module.pp` and `semodule
--checksum --show module.pp` Some time ago I started to work `--show`
but haven't finished it yet.


Petr







  reply	other threads:[~2022-01-25 15:20 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-01-13 14:39 [RFC PATCH userspace 0/5] Allow rebuilding policy store only if there were external changes to modules Ondrej Mosnacek
2022-01-13 14:39 ` [RFC PATCH userspace 1/5] libsemanage: add missing include to boolean_record.c Ondrej Mosnacek
2022-01-13 14:39 ` [RFC PATCH userspace 2/5] semodule,libsemanage: move module hashing into libsemanage Ondrej Mosnacek
2022-01-20 21:52   ` James Carter
2022-01-21 13:21     ` Ondrej Mosnacek
2022-01-25 15:17       ` Petr Lautrbach [this message]
2022-01-13 14:39 ` [RFC PATCH userspace 3/5] libsemanage: move compressed file handling into a separate object Ondrej Mosnacek
2022-01-20 21:58   ` James Carter
2022-01-13 14:39 ` [RFC PATCH userspace 4/5] libsemanage: optionally rebuild policy when modules are changed externally Ondrej Mosnacek
2022-01-20 22:08   ` James Carter
2022-01-21 13:30     ` Ondrej Mosnacek
2022-01-13 14:39 ` [RFC PATCH userspace 5/5] semodule: add command-line option to detect module changes Ondrej Mosnacek
2022-01-15 17:38   ` Christian Göttsche
2022-01-20 22:10     ` James Carter
2022-01-20 22:12   ` 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=874k5ru9nd.fsf@redhat.com \
    --to=plautrba@redhat.com \
    --cc=jwcart2@gmail.com \
    --cc=omosnace@redhat.com \
    --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 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.