lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <D05O8BUCPQL6.22850B90ITSCR@kernel.org>
Date: Thu, 28 Mar 2024 22:38:29 +0200
From: "Jarkko Sakkinen" <jarkko@...nel.org>
To: "Jarkko Sakkinen" <jarkko@...nel.org>, "Fan Wu"
 <wufan@...ux.microsoft.com>, <corbet@....net>, <zohar@...ux.ibm.com>,
 <jmorris@...ei.org>, <serge@...lyn.com>, <tytso@....edu>,
 <ebiggers@...nel.org>, <axboe@...nel.dk>, <agk@...hat.com>,
 <snitzer@...nel.org>, <eparis@...hat.com>, <paul@...l-moore.com>
Cc: <linux-doc@...r.kernel.org>, <linux-integrity@...r.kernel.org>,
 <linux-security-module@...r.kernel.org>, <fsverity@...ts.linux.dev>,
 <linux-block@...r.kernel.org>, <dm-devel@...ts.linux.dev>,
 <audit@...r.kernel.org>, <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v16 00/20] Integrity Policy Enforcement LSM (IPE)

On Thu Mar 28, 2024 at 10:36 PM EET, Jarkko Sakkinen wrote:
> On Thu Mar 28, 2024 at 10:17 PM EET, Fan Wu wrote:
> > Overview:
> > ---------
>
> s/://
>
> It is already a heading.
>
> >
> > IPE is a Linux Security Module which takes a complimentary approach to
>   
>   Integrity Policy Enforcement (IPE) is a ...
>
> > access control. Whereas existing mandatory access control mechanisms
> > base their decisions on labels and paths, IPE instead determines
> > whether or not an operation should be allowed based on immutable
> > security properties of the system component the operation is being
> > performed on.
>
> What is "a immutable property of the system component", or even,
> what is "a immutable property" and what is "a system component".
>
> These should be defined per context of use as there is no unambiguous
> definitions of these "properties".
>
> So can you add a paragraph before this defining these concepts?
> Otherwise, it would be pretty hard to review any of this.
>
> I.e. I have to make my own imaginary definitions of them and possibly
> make completely false conclusions what was meant.

This might sound like nitpicking but often in security patch sets
people get their own ideas and that leads to useless iterations
etc. so I think it is useful to be pretty formal with definitions
so that we dont end up shadow boxing...

I have ton of experience with this with SGX patches in the past.

BR, Jarkko

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ