Re: simple prob made into a security tragedy...oh well.... ;^/
On 2021/06/29 19:11, Eli Schwartz wrote:
This is a ridiculous argument and you know it. You, personally, are
writing code which does not get used in security contexts, which is your
right. This in no way means that refusing to quote variables which
"cannot be word-split" stops *any* security errors. The "illegal input"
was not related to the security bypass (as Greg points out, removing the
space prevents word splitting and executes the same security bypass code).
Your response should have been:
More likely "is", if I needed security I wouldn't likely write in
a script language, but more like with audit, w/Biba integrity and
Bell-LaPadula sensitivity models that we planned to port to linux, I'd have
written it in 'C'.
Trix or Trusted IRIX was certified, for C2+ under the then, orange
book standard. Even had a 128-bit luid, which later implementers
changed to a less parallel 'loginuid', mainly for auditing.
I'd been presenting sgi's security plan at the linux security conference in
France, as well as some presentation in London. It seems I was good at
explaining what had been a confusing security model in the place of
my then manager. I wasn't good at politics, but my manager prided himself
on his bookshelf copy of Machiavelli's, 'The Prince' as having everything
a manager needed to know... among other things, for him to be able to
put a sensitivity+integrity Policy, 'SMACK' in the linux kernel.
Instead you are arguing in bad faith...
---
You are arguing about a 1-liner that took unfiltered output
from locate to search for keywords. You wanna work that up into
bad faith, good luck.
your code is flawed, it doesn't
correctly handle indexed arrays with spaces in the key and doesn't
forbid them either.
What are you talking about?
njobs() { printf ${1:+-v $1} "%s\n" "$(jobs |wc -l)"; }
I don't see any arrays, let alone indexed.
This won't protect against all code injections, of course;
---
It does in the target environment. The key is to look at the
security policy requirements and environment before going off and making
assumptions about "faith" that might bounce back when used for
design issues relating to a 1-line search expression.
Re: simple prob made into a security tragedy...oh well.... ;^/
On Thu, Jul 01, 2021 at 02:12:10AM -0700, L A Walsh wrote:
> What are you talking about?
>
> njobs() { printf ${1:+-v $1} "%s\n" "$(jobs |wc -l)"; }
>
> I don't see any arrays, let alone indexed.
The arrays were in the calls. We demonstrated a few cases already.
Since you clearly weren't paying attention, here they are again.
First, the classic code injection:
unicorn:~$ njobs 'x[0$(date>&2)]'
Thu Jul 1 07:12:35 EDT 2021
Second, a user who wants to (legitimately) use an existing array, with
a space in the key:
unicorn:~$ declare -A jobs
unicorn:~$ njobs 'jobs[first time]'
bash: printf: `jobs[first': not a valid identifier
Third, a user who wants to (legitimately) use an existing array, where
the indexed reference is accidentally treated as a glob:
unicorn:~$ touch jobsx
unicorn:~$ njobs 'jobs[sixth]'
unicorn:~$ declare -p jobs jobsx
declare -A jobs
declare -- jobsx="0
"
Fourth, a user who accidentally or maliciously passes additional printf
options:
unicorn:~$ njobs 'foo -v bar'
unicorn:~$ declare -p foo bar
bash: declare: foo: not found
declare -- bar="0
"
Quoting "$1" in your code would stop three of these four examples from
doing the wrong thing. It makes no difference in the first case.
Looking at the Subject: header reminds me of:
43. A "quick" or "simple" question will be neither.
What you perceive as a "simple prob" (and for the love of glob, can you at
least spell out "problem" correctly?!) is absolutely NOT simple. It's the
tip of an exploding carcinogenic iceberg full of frozen soul-eating
demons. Everyone knows about this iceberg. There are buoys all around
it warning sailors to stay away. All the navigational maps have marked
this territory as too dangerous.
Despite this, you've decided it would be a great idea to have a little
picnic on top of it.
And people don't understand why we're so cranky.
Re: bash completion after a multiline string
Thanx Chet for taking time to explain. May be readline API should have a way to know that a quote ['"`] is opened ine many previous lines and the first occurence of such quote ine the current one , is a closing one. Well I guess this is too much of a trouble for something living this way for such a long time :) Cheers,
