linux-audit.redhat.com archive mirror
 help / color / mirror / Atom feed
From: Randy Dunlap <rdunlap@infradead.org>
To: Deven Bowers <deven.desai@linux.microsoft.com>,
	corbet@lwn.net, axboe@kernel.dk, agk@redhat.com,
	snitzer@redhat.com, ebiggers@kernel.org, tytso@mit.edu,
	paul@paul-moore.com, eparis@redhat.com, jmorris@namei.org,
	serge@hallyn.com
Cc: linux-security-module@vger.kernel.org, linux-doc@vger.kernel.org,
	jannh@google.com, linux-fscrypt@vger.kernel.org,
	linux-kernel@vger.kernel.org, linux-block@vger.kernel.org,
	dm-devel@redhat.com, linux-audit@redhat.com
Subject: Re: [RFC PATCH v7 07/16] ipe: add auditing support
Date: Fri, 15 Oct 2021 12:50:05 -0700	[thread overview]
Message-ID: <e4bc834b-5483-604d-7fa1-e5eafdd5ebf5@infradead.org> (raw)
In-Reply-To: <7bd474ae-3dbe-4351-fa10-ee68e5c7267c@linux.microsoft.com>

On 10/15/21 12:25 PM, Deven Bowers wrote:
> On 10/13/2021 3:54 PM, Randy Dunlap wrote:
>> Hi,
>>
>> On 10/13/21 12:06 PM, deven.desai@linux.microsoft.com wrote:
>>> diff --git a/security/ipe/Kconfig b/security/ipe/Kconfig
>>> index c4503083e92d..ef556b66e674 100644
>>> --- a/security/ipe/Kconfig
>>> +++ b/security/ipe/Kconfig
>>> @@ -17,3 +17,55 @@ menuconfig SECURITY_IPE
>>>         requirements on the fly.
>>>           If unsure, answer N.
>>> +
>>> +if SECURITY_IPE
>>> +
>>> +choice
>>> +    prompt "Hash algorithm used in auditing policies"
>>> +    default IPE_AUDIT_HASH_SHA1
>>> +    depends on AUDIT
>>> +    help
>>> +        Specify the hash algorithm used when auditing policies.
>>> +        The hash is used to uniquely identify a policy from other
>>> +        policies on the system.
>>> +
>>> +        If unsure, leave default.
>>> +
>>> +    config IPE_AUDIT_HASH_SHA1
>>> +        bool "sha1"
>>> +        depends on CRYPTO_SHA1
>>> +        help
>>> +            Use the SHA128 algorithm to hash policies
>>> +            in the audit records.
>>> +
>>> +    config IPE_AUDIT_HASH_SHA256
>>> +        bool "sha256"
>>> +        depends on CRYPTO_SHA256
>>> +        help
>>> +            Use the SHA256 algorithm to hash policies
>>> +            in the audit records.
>>> +
>>> +    config IPE_AUDIT_HASH_SHA384
>>> +        bool "sha384"
>>> +        depends on CRYPTO_SHA512
>>> +        help
>>> +            Use the SHA384 algorithm to hash policies
>>> +            in the audit records
>>> +
>>> +    config IPE_AUDIT_HASH_SHA512
>>> +        bool "sha512"
>>> +        depends on CRYPTO_SHA512
>>> +        help
>>> +            Use the SHA512 algorithm to hash policies
>>> +            in the audit records
>>> +endchoice
>>> +
>>> +config IPE_AUDIT_HASH_ALG
>>> +    string
>>> +    depends on AUDIT
>>> +    default "sha1" if IPE_AUDIT_HASH_SHA1
>>> +    default "sha256" if IPE_AUDIT_HASH_SHA256
>>> +    default "sha384" if IPE_AUDIT_HASH_SHA384
>>> +    default "sha512" if IPE_AUDIT_HASH_SHA512
>>> +
>>> +endif
>>
>> Please follow coding-style for Kconfig files:
>>
>> (from Documentation/process/coding-style.rst, section 10):
>>
>> For all of the Kconfig* configuration files throughout the source tree,
>> the indentation is somewhat different.  Lines under a ``config`` definition
>> are indented with one tab, while help text is indented an additional two
>> spaces.
>>
> Oof. That's embarrassing. Sorry, I'll fix this for v8.
> 
> While I'm at it, is the help text required for choice configs?
> checkpatch --strict complains with a warning without them, but
> I see other places in the tree where help text is omitted for
> these configs attached to a choice.

Does checkpatch complain about what you have above
or did you add that help text to keep it from complaining?


> Documentation/process/* doesn't seem to have any guidance, nor
> Documentation/kbuild/* on whether it is safe to ignore that
> checkpatch warning.

Yeah, I don't think that we have any good guidance on that.

I would say that if the choice prompt provides good/adequate
help info, then each 'config' inside the choice block does not
need help text. OTOH, if the choice prompt has little/no help
info, then each 'config' under it should have some useful info.

I only looked in arch/x86/Kconfig, init/Kconfig, and lib/Kconfig.debug,
but you can see either help text method being used in those.

And then if the help text is adequate in either one of those
methods, I would just ignore the checkpatch complaints.
It's just a guidance tool.

HTH.

-- 
~Randy

--
Linux-audit mailing list
Linux-audit@redhat.com
https://listman.redhat.com/mailman/listinfo/linux-audit

  reply	other threads:[~2021-10-15 20:03 UTC|newest]

Thread overview: 63+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-10-13 19:06 [RFC PATCH v7 00/16] Integrity Policy Enforcement (IPE) deven.desai
2021-10-13 19:06 ` [RFC PATCH v7 01/16] security: add ipe lsm & initial context creation deven.desai
2021-10-13 19:06 ` [RFC PATCH v7 02/16] ipe: add policy parser deven.desai
2021-10-13 19:06 ` [RFC PATCH v7 03/16] ipe: add evaluation loop deven.desai
2021-10-13 19:06 ` [RFC PATCH v7 04/16] ipe: add userspace interface deven.desai
2021-11-03  9:42   ` Roberto Sassu
2021-11-04 16:50     ` Deven Bowers
2021-10-13 19:06 ` [RFC PATCH v7 05/16] ipe: add LSM hooks on execution and kernel read deven.desai
2021-10-13 20:04   ` Casey Schaufler
2021-10-15 19:25     ` Deven Bowers
2021-10-25 12:22   ` Roberto Sassu
2021-10-26 19:03     ` Deven Bowers
2021-10-27  8:56       ` Roberto Sassu
2021-10-13 19:06 ` [RFC PATCH v7 06/16] uapi|audit: add trust audit message definitions deven.desai
2021-10-13 19:06 ` [RFC PATCH v7 07/16] ipe: add auditing support deven.desai
2021-10-13 20:02   ` Steve Grubb
2021-10-15 19:25     ` Deven Bowers
2021-11-02 19:44       ` Steve Grubb
2021-11-04 16:59         ` Deven Bowers
2021-10-13 22:54   ` Randy Dunlap
2021-10-15 19:25     ` Deven Bowers
2021-10-15 19:50       ` Randy Dunlap [this message]
2021-10-26 19:03         ` Deven Bowers
2021-10-13 19:06 ` [RFC PATCH v7 08/16] ipe: add permissive toggle deven.desai
2021-10-13 19:06 ` [RFC PATCH v7 09/16] ipe: introduce 'boot_verified' as a trust provider deven.desai
2021-10-13 19:06 ` [RFC PATCH v7 10/16] fs|dm-verity: add block_dev LSM blob and submit dm-verity data deven.desai
2021-10-13 19:06 ` [RFC PATCH v7 11/16] ipe: add support for dm-verity as a trust provider deven.desai
2021-11-25  9:37   ` Roberto Sassu
2021-11-30 18:55     ` Deven Bowers
2021-12-01 16:37       ` [RFC][PATCH] device mapper: Add builtin function dm_get_status() Roberto Sassu
2021-12-01 16:43         ` Roberto Sassu
2021-12-02  7:20         ` Christoph Hellwig
2021-12-02  7:59           ` Roberto Sassu
2021-12-02  8:44             ` Christoph Hellwig
2021-12-02  9:29               ` Roberto Sassu
2021-12-03  6:52                 ` Christoph Hellwig
2021-12-03 10:20                   ` Roberto Sassu
2021-12-06 10:57                     ` Roberto Sassu
2021-10-13 19:06 ` [RFC PATCH v7 12/16] fsverity|security: add security hooks to fsverity digest and signature deven.desai
2021-10-13 19:24   ` Eric Biggers
2021-10-15 19:25     ` Deven Bowers
2021-10-15 20:11       ` Eric Biggers
2021-10-20 15:08         ` Roberto Sassu
2021-10-22 16:31           ` Roberto Sassu
2021-10-26 19:03             ` Deven Bowers
2021-10-27  8:41               ` Roberto Sassu
2021-10-26 19:03         ` Deven Bowers
2021-10-27  9:34           ` Roberto Sassu
2021-10-28  3:48           ` Eric Biggers
2021-10-28 18:11             ` Deven Bowers
2021-11-03 12:28       ` Roberto Sassu
2021-11-04 17:12         ` Deven Bowers
2021-10-13 19:06 ` [RFC PATCH v7 13/16] ipe: enable support for fs-verity as a trust provider deven.desai
2021-10-13 19:06 ` [RFC PATCH v7 14/16] scripts: add boot policy generation program deven.desai
2021-11-03 16:43   ` Roberto Sassu
2021-11-03 16:53     ` Roberto Sassu
2021-11-04 16:52       ` Deven Bowers
2021-10-13 19:06 ` [RFC PATCH v7 15/16] ipe: kunit tests deven.desai
2021-10-13 19:06 ` [RFC PATCH v7 16/16] documentation: add ipe documentation deven.desai
2021-10-25 11:30 ` [RFC PATCH v7 00/16] Integrity Policy Enforcement (IPE) Roberto Sassu
2021-10-26 19:03   ` Deven Bowers
2021-10-27  8:26     ` Roberto Sassu
2021-10-28 20:36       ` Deven Bowers

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=e4bc834b-5483-604d-7fa1-e5eafdd5ebf5@infradead.org \
    --to=rdunlap@infradead.org \
    --cc=agk@redhat.com \
    --cc=axboe@kernel.dk \
    --cc=corbet@lwn.net \
    --cc=deven.desai@linux.microsoft.com \
    --cc=dm-devel@redhat.com \
    --cc=ebiggers@kernel.org \
    --cc=eparis@redhat.com \
    --cc=jannh@google.com \
    --cc=jmorris@namei.org \
    --cc=linux-audit@redhat.com \
    --cc=linux-block@vger.kernel.org \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-fscrypt@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-security-module@vger.kernel.org \
    --cc=paul@paul-moore.com \
    --cc=serge@hallyn.com \
    --cc=snitzer@redhat.com \
    --cc=tytso@mit.edu \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).