-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 12/14/15 12:17 AM, Mike Frysinger wrote:
>
> (1) the examples i already provided do not involve the user at all, and
> include systems where the user has no direct access to the shell.
You didn't really provide any examples. You mentioned
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 12/14/15 12:32 AM, Mike Frysinger wrote:
> On 13 Dec 2015 17:24, Chet Ramey wrote:
>> On 12/12/15 4:01 PM, Mike Frysinger wrote:
>>> Today, if you have a script that lives on a noexec mount point, the
>>> kernel will reject attempts to run it
On 12/16/15 3:29 PM, John McKown wrote:
> FWIW (not much), I'm going to go with Chet on this. It may be my ignorance
> speaking, but what can I do in a BASH shell script which I cannot do (at
> all) just by entering the commands by hand?
That's where the scope of the proposal makes a difference.
On 12/15/15 4:53 AM, konsolebox wrote:
> Ok I accept your point. So it's actually about `source` and `bash
> file`, correct? So would this mean every script I `source` would need
> +x bit now? And if it's not about the +x bit and only about `noexec`,
> would stuff I place that I would want to
On Tue, Dec 15, 2015 at 7:30 AM, Mike Frysinger wrote:
> On 15 Dec 2015 06:47, konsolebox wrote:
>> t On Mon, Dec 14, 2015 at 1:17 PM, Mike Frysinger wrote:
>> > On 13 Dec 2015 16:50, konsolebox wrote:
>> >> On Sun, Dec 13, 2015 at 5:01 AM, Mike Frysinger
On 15 Dec 2015 06:47, konsolebox wrote:
> t On Mon, Dec 14, 2015 at 1:17 PM, Mike Frysinger wrote:
> > On 13 Dec 2015 16:50, konsolebox wrote:
> >> On Sun, Dec 13, 2015 at 5:01 AM, Mike Frysinger wrote:
> >> > Today, if you have a script that lives on a noexec mount point, the
t On Mon, Dec 14, 2015 at 1:17 PM, Mike Frysinger wrote:
> On 13 Dec 2015 16:50, konsolebox wrote:
>> On Sun, Dec 13, 2015 at 5:01 AM, Mike Frysinger wrote:
>> > Today, if you have a script that lives on a noexec mount point, the
>> > kernel will reject attempts to run it
2015-12-12 17:53:35 -0500, Mike Frysinger:
[...]
> > It will almost
> > certainly get in the way of a reasonable use case.
>
> can you name a reasonable use case this breaks ?
bash << EOF
some code
EOF
here-documents with many shells (including bash) are implemented
as deleted temporary files
2015-12-12 16:01:26 -0500, Mike Frysinger:
[...]
> This is not a perfect solution as it can still be worked around by
> inlining the code itself:
> $ bash -c "$(cat /dev/shm/test.sh)"
> hi
Or
cat /dev/shm/test.sh | bash
I think this kind of hardening is better left to things like
On 13 Dec 2015 12:21, Piotr Grzybowski wrote:
> On Sat, Dec 12, 2015 at 11:53 PM, Mike Frysinger wrote:
> > On 12 Dec 2015 15:06, Bob Proulx wrote:
> >> It will almost
> >> certainly get in the way of a reasonable use case.
> >
> > can you name a reasonable use case this breaks ?
>
> source
On 12 Dec 2015 23:05, Stephane Chazelas wrote:
> 2015-12-12 16:01:26 -0500, Mike Frysinger:
> [...]
> > This is not a perfect solution as it can still be worked around by
> > inlining the code itself:
> > $ bash -c "$(cat /dev/shm/test.sh)"
> > hi
>
> Or
>
> cat /dev/shm/test.sh | bash
On 12/12/15 4:01 PM, Mike Frysinger wrote:
> From: Mike Frysinger
>
> Today, if you have a script that lives on a noexec mount point, the
> kernel will reject attempts to run it directly:
> $ printf '#!/bin/sh\necho hi\n' > /dev/shm/test.sh
> $ chmod a+rx
On 13 Dec 2015 17:24, Chet Ramey wrote:
> On 12/12/15 4:01 PM, Mike Frysinger wrote:
> > Today, if you have a script that lives on a noexec mount point, the
> > kernel will reject attempts to run it directly:
> > $ printf '#!/bin/sh\necho hi\n' > /dev/shm/test.sh
> > $ chmod a+rx
On 13 Dec 2015 16:50, konsolebox wrote:
> On Sun, Dec 13, 2015 at 5:01 AM, Mike Frysinger wrote:
> > Today, if you have a script that lives on a noexec mount point, the
> > kernel will reject attempts to run it directly:
> > $ printf '#!/bin/sh\necho hi\n' > /dev/shm/test.sh
> > $ chmod a+rx
On Sat, Dec 12, 2015 at 3:01 PM, Mike Frysinger wrote:
> From: Mike Frysinger
>
> Today, if you have a script that lives on a noexec mount point, the
> kernel will reject attempts to run it directly:
> $ printf '#!/bin/sh\necho hi\n' > /dev/shm/test.sh
On 12 Dec 2015 22:12, John McKown wrote:
> On Sat, Dec 12, 2015 at 3:01 PM, Mike Frysinger wrote:
> > Today, if you have a script that lives on a noexec mount point, the
> > kernel will reject attempts to run it directly:
> > $ printf '#!/bin/sh\necho hi\n' > /dev/shm/test.sh
> > $ chmod a+rx
On 12 Dec 2015 15:06, Bob Proulx wrote:
> Mike Frysinger wrote:
> > But bash itself has no problem running this file:
> > $ bash /dev/shm/test.sh
> > hi
> >...
> > This detracts from the security of the overall system. People
> > writing scripts sometimes want to save/restore state (like
> >
From: Mike Frysinger
Today, if you have a script that lives on a noexec mount point, the
kernel will reject attempts to run it directly:
$ printf '#!/bin/sh\necho hi\n' > /dev/shm/test.sh
$ chmod a+rx /dev/shm/test.sh
$ /dev/shm/test.sh
bash: /dev/shm/test.sh:
Hello Mike,
you want to forbid reading and interpreting scripts from the mount
point that is marked as noexec. If nothing gets executed from the
noexec area, as in your example, this is going to far.
After this, do I have to move all my scripts away from the noexec
area if I want bash to read
Mike Frysinger wrote:
> But bash itself has no problem running this file:
> $ bash /dev/shm/test.sh
> hi
>...
> This detracts from the security of the overall system. People
> writing scripts sometimes want to save/restore state (like
> variables) and will restore the content from a noexec
20 matches
Mail list logo