All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Mickaël Salaün" <mic@digikod.net>
To: Pavel Machek <pavel@ucw.cz>
Cc: "Madhavan T. Venkataraman" <madvenka@linux.microsoft.com>,
	kernel-hardening@lists.openwall.com, linux-api@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org,
	linux-fsdevel@vger.kernel.org, linux-integrity@vger.kernel.org,
	linux-kernel@vger.kernel.org,
	linux-security-module@vger.kernel.org, oleg@redhat.com,
	x86@kernel.org, luto@kernel.org, David.Laight@ACULAB.COM,
	fweimer@redhat.com, mark.rutland@arm.com
Subject: Re: [PATCH v2 0/4] [RFC] Implement Trampoline File Descriptor
Date: Fri, 25 Sep 2020 12:12:01 +0200	[thread overview]
Message-ID: <eec5d097-c70f-365b-3548-66726ad49f04@digikod.net> (raw)
In-Reply-To: <20200924220540.GA13185@amd>


On 25/09/2020 00:05, Pavel Machek wrote:
> Hi!
> 
>>>>> I believe you should simply delete confusing "introduction" and
>>>>> provide details of super-secure system where your patches would be
>>>>> useful, instead.
>>>>
>>>> This RFC talks about converting dynamic code (which cannot be authenticated)
>>>> to static code that can be authenticated using signature verification. That
>>>> is the scope of this RFC.
>>>>
>>>> If I have not been clear before, by dynamic code, I mean machine code that is
>>>> dynamic in nature. Scripts are beyond the scope of this RFC.
>>>>
>>>> Also, malware compiled from sources is not dynamic code. That is orthogonal
>>>> to this RFC. If such malware has a valid signature that the kernel permits its
>>>> execution, we have a systemic problem.
>>>>
>>>> I am not saying that script authentication or compiled malware are not problems.
>>>> I am just saying that this RFC is not trying to solve all of the security problems.
>>>> It is trying to define one way to convert dynamic code to static code to address
>>>> one class of problems.
>>>
>>> Well, you don't have to solve all problems at once.
>>>
>>> But solutions have to exist, and AFAIK in this case they don't. You
>>> are armoring doors, but ignoring open windows.
>>
>> FYI, script execution is being addressed (for the kernel part) by this
>> patch series:
>> https://lore.kernel.org/lkml/20200924153228.387737-1-mic@digikod.net/
> 
> Ok.
> 
>>> Or very probably you are thinking about something different than
>>> normal desktop distros (Debian 10). Because on my systems, I have
>>> python, gdb and gcc...
>>
>> It doesn't make sense for a tailored security system to leave all these
>> tools available to an attacker.
> 
> And it also does not make sense to use "trampoline file descriptor" on
> generic system... while W^X should make sense there.

Well, as said before, (full/original/system-wide) W^X may require
trampfd (as well as other building-blocks).

I guess most Linux deployments are not on "generic systems"
anyway (even if they may be based on generic distros), and W^X
contradicts the fact that users/attackers can do whatever they want on
the system.

> 
>>> It would be nice to specify what other pieces need to be present for
>>> this to make sense -- because it makes no sense on Debian 10.
>>
>> Not all kernel features make sense for a generic/undefined usage,
>> especially specific security mechanisms (e.g. SELinux, Smack, Tomoyo,
>> SafeSetID, LoadPin, IMA, IPE, secure/trusted boot, lockdown, etc.), but
>> they can still be definitely useful.
> 
> Yep... so... I'd expect something like... "so you have single-purpose
> system

No one talked about a single-purpose system.

> with all script interpreters removed,

Not necessarily with the patch series I pointed out just before.

> IMA hashing all the files
> to make sure they are not modified, and W^X enabled.

System-wide W^X is not only for memory, and as Madhavan said: "this RFC
pertains to converting dynamic [writable] machine code to static
[non-writable] code".

> Attacker can
> still execute code after buffer overflow by .... and trapoline file
> descriptor addrsses that"... so that people running generic systems
> can stop reading after first sentence.

Are you proposing to add a
"[feature-not-useful-without-a-proper-system-configuration]" tag in
subjects? :)

WARNING: multiple messages have this Message-ID (diff)
From: "Mickaël Salaün" <mic@digikod.net>
To: Pavel Machek <pavel@ucw.cz>
Cc: fweimer@redhat.com, mark.rutland@arm.com,
	kernel-hardening@lists.openwall.com, linux-api@vger.kernel.org,
	x86@kernel.org, linux-kernel@vger.kernel.org, oleg@redhat.com,
	"Madhavan T. Venkataraman" <madvenka@linux.microsoft.com>,
	linux-security-module@vger.kernel.org, David.Laight@ACULAB.COM,
	luto@kernel.org, linux-fsdevel@vger.kernel.org,
	linux-integrity@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH v2 0/4] [RFC] Implement Trampoline File Descriptor
Date: Fri, 25 Sep 2020 12:12:01 +0200	[thread overview]
Message-ID: <eec5d097-c70f-365b-3548-66726ad49f04@digikod.net> (raw)
In-Reply-To: <20200924220540.GA13185@amd>


On 25/09/2020 00:05, Pavel Machek wrote:
> Hi!
> 
>>>>> I believe you should simply delete confusing "introduction" and
>>>>> provide details of super-secure system where your patches would be
>>>>> useful, instead.
>>>>
>>>> This RFC talks about converting dynamic code (which cannot be authenticated)
>>>> to static code that can be authenticated using signature verification. That
>>>> is the scope of this RFC.
>>>>
>>>> If I have not been clear before, by dynamic code, I mean machine code that is
>>>> dynamic in nature. Scripts are beyond the scope of this RFC.
>>>>
>>>> Also, malware compiled from sources is not dynamic code. That is orthogonal
>>>> to this RFC. If such malware has a valid signature that the kernel permits its
>>>> execution, we have a systemic problem.
>>>>
>>>> I am not saying that script authentication or compiled malware are not problems.
>>>> I am just saying that this RFC is not trying to solve all of the security problems.
>>>> It is trying to define one way to convert dynamic code to static code to address
>>>> one class of problems.
>>>
>>> Well, you don't have to solve all problems at once.
>>>
>>> But solutions have to exist, and AFAIK in this case they don't. You
>>> are armoring doors, but ignoring open windows.
>>
>> FYI, script execution is being addressed (for the kernel part) by this
>> patch series:
>> https://lore.kernel.org/lkml/20200924153228.387737-1-mic@digikod.net/
> 
> Ok.
> 
>>> Or very probably you are thinking about something different than
>>> normal desktop distros (Debian 10). Because on my systems, I have
>>> python, gdb and gcc...
>>
>> It doesn't make sense for a tailored security system to leave all these
>> tools available to an attacker.
> 
> And it also does not make sense to use "trampoline file descriptor" on
> generic system... while W^X should make sense there.

Well, as said before, (full/original/system-wide) W^X may require
trampfd (as well as other building-blocks).

I guess most Linux deployments are not on "generic systems"
anyway (even if they may be based on generic distros), and W^X
contradicts the fact that users/attackers can do whatever they want on
the system.

> 
>>> It would be nice to specify what other pieces need to be present for
>>> this to make sense -- because it makes no sense on Debian 10.
>>
>> Not all kernel features make sense for a generic/undefined usage,
>> especially specific security mechanisms (e.g. SELinux, Smack, Tomoyo,
>> SafeSetID, LoadPin, IMA, IPE, secure/trusted boot, lockdown, etc.), but
>> they can still be definitely useful.
> 
> Yep... so... I'd expect something like... "so you have single-purpose
> system

No one talked about a single-purpose system.

> with all script interpreters removed,

Not necessarily with the patch series I pointed out just before.

> IMA hashing all the files
> to make sure they are not modified, and W^X enabled.

System-wide W^X is not only for memory, and as Madhavan said: "this RFC
pertains to converting dynamic [writable] machine code to static
[non-writable] code".

> Attacker can
> still execute code after buffer overflow by .... and trapoline file
> descriptor addrsses that"... so that people running generic systems
> can stop reading after first sentence.

Are you proposing to add a
"[feature-not-useful-without-a-proper-system-configuration]" tag in
subjects? :)

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2020-09-25 10:19 UTC|newest]

Thread overview: 111+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <210d7cd762d5307c2aa1676705b392bd445f1baa>
2020-09-16 15:08 ` [PATCH v2 0/4] [RFC] Implement Trampoline File Descriptor madvenka
2020-09-16 15:08   ` madvenka
2020-09-16 15:08   ` [PATCH v2 1/4] [RFC] fs/trampfd: Implement the trampoline file descriptor API madvenka
2020-09-16 15:08     ` madvenka
2020-09-16 15:08   ` [PATCH v2 2/4] [RFC] x86/trampfd: Provide support for the trampoline file descriptor madvenka
2020-09-16 15:08     ` madvenka
2020-09-17  1:10     ` kernel test robot
2020-09-17  3:04     ` kernel test robot
2020-09-16 15:08   ` [PATCH v2 3/4] [RFC] arm64/trampfd: " madvenka
2020-09-16 15:08     ` madvenka
2020-09-16 15:08   ` [PATCH v2 4/4] [RFC] arm/trampfd: " madvenka
2020-09-16 15:08     ` madvenka
2020-09-17  1:04   ` [PATCH v2 0/4] [RFC] Implement Trampoline File Descriptor Florian Weimer
2020-09-17  1:04     ` Florian Weimer
2020-09-17  1:04     ` Florian Weimer
2020-09-17 15:36     ` Madhavan T. Venkataraman
2020-09-17 15:36       ` Madhavan T. Venkataraman
2020-09-17 15:57       ` Madhavan T. Venkataraman
2020-09-17 15:57         ` Madhavan T. Venkataraman
2020-09-17 16:01         ` Florian Weimer
2020-09-17 16:01           ` Florian Weimer
2020-09-17 16:01           ` Florian Weimer
2020-09-23  1:46       ` Arvind Sankar
2020-09-23  1:46         ` Arvind Sankar
2020-09-23  9:11         ` Arvind Sankar
2020-09-23  9:11           ` Arvind Sankar
2020-09-23 19:17           ` Madhavan T. Venkataraman
2020-09-23 19:17             ` Madhavan T. Venkataraman
2020-09-23 19:51             ` Arvind Sankar
2020-09-23 19:51               ` Arvind Sankar
2020-09-23 23:51               ` Madhavan T. Venkataraman
2020-09-23 23:51                 ` Madhavan T. Venkataraman
2020-09-24 20:23               ` Madhavan T. Venkataraman
2020-09-24 20:23                 ` Madhavan T. Venkataraman
2020-09-24 20:52                 ` Florian Weimer
2020-09-24 20:52                   ` Florian Weimer
2020-09-24 20:52                   ` Florian Weimer
2020-09-25 22:22                   ` Madhavan T. Venkataraman
2020-09-25 22:22                     ` Madhavan T. Venkataraman
2020-09-27 18:25                     ` Madhavan T. Venkataraman
2020-09-27 18:25                       ` Madhavan T. Venkataraman
2020-10-03  9:43                       ` Jay K
2020-10-03  9:43                         ` Jay K
2020-09-24 22:13                 ` Pavel Machek
2020-09-24 22:13                   ` Pavel Machek
2020-09-24 23:43                 ` Arvind Sankar
2020-09-24 23:43                   ` Arvind Sankar
2020-09-25 22:44                   ` Madhavan T. Venkataraman
2020-09-25 22:44                     ` Madhavan T. Venkataraman
2020-09-26 15:55                     ` Arvind Sankar
2020-09-26 15:55                       ` Arvind Sankar
2020-09-27 17:59                       ` Madhavan T. Venkataraman
2020-09-27 17:59                         ` Madhavan T. Venkataraman
2020-09-23  2:50       ` Jay K
2020-09-23  2:50         ` Jay K
2020-09-22 21:53 ` madvenka
2020-09-22 21:53   ` madvenka
2020-09-22 21:53   ` [PATCH v2 1/4] [RFC] fs/trampfd: Implement the trampoline file descriptor API madvenka
2020-09-22 21:53     ` madvenka
2020-09-22 21:53   ` [PATCH v2 2/4] [RFC] x86/trampfd: Provide support for the trampoline file descriptor madvenka
2020-09-22 21:53     ` madvenka
2020-09-23 13:40     ` kernel test robot
2020-09-22 21:53   ` [PATCH v2 3/4] [RFC] arm64/trampfd: " madvenka
2020-09-22 21:53     ` madvenka
2020-09-22 21:53   ` [PATCH v2 4/4] [RFC] arm/trampfd: " madvenka
2020-09-22 21:53     ` madvenka
2020-09-22 21:54   ` [PATCH v2 0/4] [RFC] Implement Trampoline File Descriptor Madhavan T. Venkataraman
2020-09-22 21:54     ` Madhavan T. Venkataraman
2020-09-23  8:14   ` Pavel Machek
2020-09-23  8:14     ` Pavel Machek
2020-09-23  9:14     ` Solar Designer
2020-09-23  9:14       ` Solar Designer
2020-09-23 14:11       ` Solar Designer
2020-09-23 14:11         ` Solar Designer
2020-09-23 15:18         ` Pavel Machek
2020-09-23 15:18           ` Pavel Machek
2020-09-23 18:00           ` Solar Designer
2020-09-23 18:00             ` Solar Designer
2020-09-23 18:21             ` Solar Designer
2020-09-23 18:21               ` Solar Designer
2020-09-23 14:39       ` Florian Weimer
2020-09-23 14:39         ` Florian Weimer
2020-09-23 14:39         ` Florian Weimer
2020-09-23 18:09         ` Andy Lutomirski
2020-09-23 18:09           ` Andy Lutomirski
2020-09-23 18:11         ` Solar Designer
2020-09-23 18:11           ` Solar Designer
2020-09-23 18:49           ` Arvind Sankar
2020-09-23 18:49             ` Arvind Sankar
2020-09-23 23:53         ` Madhavan T. Venkataraman
2020-09-23 23:53           ` Madhavan T. Venkataraman
2020-09-23 19:41       ` Madhavan T. Venkataraman
2020-09-23 19:41         ` Madhavan T. Venkataraman
2020-09-23 18:10     ` James Morris
2020-09-23 18:10       ` James Morris
2020-09-23 18:32     ` Madhavan T. Venkataraman
2020-09-23 18:32       ` Madhavan T. Venkataraman
2020-09-23  8:42   ` Pavel Machek
2020-09-23  8:42     ` Pavel Machek
2020-09-23 18:56     ` Madhavan T. Venkataraman
2020-09-23 18:56       ` Madhavan T. Venkataraman
2020-09-23 20:51       ` Pavel Machek
2020-09-23 20:51         ` Pavel Machek
2020-09-23 23:04         ` Madhavan T. Venkataraman
2020-09-23 23:04           ` Madhavan T. Venkataraman
2020-09-24 16:44         ` Mickaël Salaün
2020-09-24 16:44           ` Mickaël Salaün
2020-09-24 22:05           ` Pavel Machek
2020-09-24 22:05             ` Pavel Machek
2020-09-25 10:12             ` Mickaël Salaün [this message]
2020-09-25 10:12               ` Mickaël Salaün

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=eec5d097-c70f-365b-3548-66726ad49f04@digikod.net \
    --to=mic@digikod.net \
    --cc=David.Laight@ACULAB.COM \
    --cc=fweimer@redhat.com \
    --cc=kernel-hardening@lists.openwall.com \
    --cc=linux-api@vger.kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-integrity@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-security-module@vger.kernel.org \
    --cc=luto@kernel.org \
    --cc=madvenka@linux.microsoft.com \
    --cc=mark.rutland@arm.com \
    --cc=oleg@redhat.com \
    --cc=pavel@ucw.cz \
    --cc=x86@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.