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 n
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.
-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 direct
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?
On Wed, Dec 16, 2015 at 2:23 PM, Chet Ramey wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
>
-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 Chr
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 wrote:
>> >> > Today, if you have a scrip
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
> >> > kernel will r
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 directly:
>> > $ printf
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 /dev/shm/test.
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 /media
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
right
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 /d
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 /dev/shm/test.sh
> $ /dev/shm/test.
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 (t
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
selinux/app
hi,
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 /media/noexecmountpoint/sh/functions.sh;
find_all_files_with_e
On Sun, Dec 13, 2015 at 5:01 AM, 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 /dev/shm/test.sh
> $ /d
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 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
> $ chmod a+rx /dev/shm/test.sh
> $ /
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
> > v
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 poi
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 th
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: Permission denied
But bash
23 matches
Mail list logo
