Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 14 Jun 2017 16:28:45 +0200
From: Solar Designer <solar@...nwall.com>
To: Jann Horn <jannh@...gle.com>
Cc: Matt Brown <matt@...tt.com>,
	Kernel Hardening <kernel-hardening@...ts.openwall.com>
Subject: Re: Re: [PATCH v2 1/1] Add Trusted Path Execution as a stackable LSM

On Wed, Jun 14, 2017 at 03:15:22PM +0200, Jann Horn wrote:
> Some random related issues:
> 
> Scripts with shebang lines like "#!/usr/bin/env python" probably wouldn't
> work anymore, at least not without special-case logic, because in this case,
> env has to invoke python.

Why would this break?  If both env and python are in trusted paths, it
should work with TPE just fine.  (But then TPE is rather ineffective.)

> ssh and ssh-agent can load libraries from paths passed on the command
> line, by design.
> The alsa client library loads libraries from paths specified in user-owned
> config files.
> 
> If you can use dd (or anything else that permits writing to a specific
> position in a
> file), you should be able to directly overwrite the memory of a
> process using something like
> "dd of=/proc/self/mem bs=1 seek=$STARTADDRESS < new_data".
> I think one way to do this remotely is to use SFTP.

IIRC, /proc/self/mem requires mmap() and won't work with dd's write().

> Bash has a built-in named "enable" that can load shared libraries directly
> into the shell.
> 
> These are just some random examples I came up with relatively quickly,
> there are probably more.

Thanks.  The ssh, alsa, and bash "enable" examples are probably valid.

Alexander

Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.