[GIT PULL] LSM patches for v6.1

[Eric W. Biederman]

Paul Moore <paul at paul-moore.com> writes:

> On Wed, Oct 5, 2022 at 8:39 AM Eric W. Biederman <ebiederm at xmission.com> wrote:
>> Linus Torvalds <torvalds at linux-foundation.org> writes:
>
> ...
>
>> > I'm not saying that an LSM is the only place to do it, but I don't
>> > think there have been any better suggestions either.
>>
>> I don't know.  I tried to have the conversation and Paul shut it down.
>
> I would encourage anyone reading the above statement to look at the
> previous discussion, links were provided at the top of this thread in
> the original pull request.

Or they can just look below at your defense of out of tree code.
Where you again refuse to consider the other point of view.

>> Effectively he said that where two or more out of tree LSM policies want
>> something it makes no sense to discussion the actual reasons people want
>> to use the hook.
>
> Runtime kernel configuration is inherently "out of tree", this
> includes not only loadable LSM security policies (e.g. a SELinux
> policy), the system's firewall configuration, things like sysctl.conf,
> and countless others.  Please understand that "out of tree" in this
> context is not the same as when it is used in the context of kernel
> code; the former is actually a positive thing ("look we can configure
> the kernel behavior the way we want!") while the latter is a
> maintenance and support nightmare.

Paul are you saying my experience with /proc/net pointing incorrectly at
/proc/self/net instead of /proc/thread-self/net is invalid?

Paul are you saying that my experience with LSM needed a hack for
buggy LSMs in __ptrace_may_access since Jun 2006 is invalid?

My experience with the conditionals and the policy (not just on/off
configuration) existing in userspace is very much the maintenance and
support nightmare you have been describing.

In this case it is compounded because the mechanism chosen to alert
userspace of a failure (the error code) is chosen by userspace.
Further this is a mechanism that does cause silent application failures.

Do you see how it could be a concern with silent application failures
and no control in the kernel to fix anything if/when this turns into a
real world problem?  Yes, I finally found the time and tested and
verified that is the case.


I am also wondering how you see it makes sense to add userspace
functionality without discussing it on linux-api, and not documenting
what is being added?  It is easy to overlook but it was suggested.

I am wondering how you feel about adding a mechanism to the kernel
that results in userspace breakage if used?

Eric