Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #194910 > unrolled thread

encryption

Back to article view | Back to linux.debian.user

Contents

  encryption Brian <ad44@cityscape.co.uk> - 2018-04-20 21:40 +0200
    Re: encryption Greg Wooledge <wooledg@eeg.ccf.org> - 2018-04-20 22:00 +0200
    Re: encryption David Christensen <dpchrist@holgerdanske.com> - 2018-04-21 02:10 +0200
      Re: encryption Brian <ad44@cityscape.co.uk> - 2018-04-21 17:30 +0200
        Re: encryption john doe <johndoe65534@mail.com> - 2018-04-21 17:40 +0200
          Re: encryption David Christensen <dpchrist@holgerdanske.com> - 2018-04-21 22:00 +0200
            Re: encryption john doe <johndoe65534@mail.com> - 2018-04-22 08:30 +0200
              Re: encryption David Christensen <dpchrist@holgerdanske.com> - 2018-04-22 20:30 +0200
        Re: encryption Glenn English <ghe2001@gmail.com> - 2018-04-21 19:00 +0200
          Re: encryption David Christensen <dpchrist@holgerdanske.com> - 2018-04-21 22:30 +0200
        Re: encryption David Christensen <dpchrist@holgerdanske.com> - 2018-04-21 21:50 +0200
          Re: encryption David Wright <deblis@lionunicorn.co.uk> - 2018-04-22 18:20 +0200
            Re: encryption Brian <ad44@cityscape.co.uk> - 2018-04-22 18:50 +0200
              Re: encryption David Wright <deblis@lionunicorn.co.uk> - 2018-04-23 10:50 +0200
                Re: encryption Brian <ad44@cityscape.co.uk> - 2018-04-23 13:20 +0200
                  Re: encryption David Wright <deblis@lionunicorn.co.uk> - 2018-04-24 20:50 +0200
    Re: encryption David Wright <deblis@lionunicorn.co.uk> - 2018-04-21 18:40 +0200
      Re: encryption Brian <ad44@cityscape.co.uk> - 2018-04-21 20:20 +0200
        Re: encryption David Wright <deblis@lionunicorn.co.uk> - 2018-04-21 21:00 +0200
          Re: encryption Brian <ad44@cityscape.co.uk> - 2018-04-21 21:20 +0200
            Re: encryption David Christensen <dpchrist@holgerdanske.com> - 2018-04-21 23:30 +0200
            Re: encryption David Wright <deblis@lionunicorn.co.uk> - 2018-04-22 04:30 +0200
              Re: encryption Curt <curty@free.fr> - 2018-04-22 11:20 +0200
                Re: encryption Reco <recoverym4n@gmail.com> - 2018-04-22 11:50 +0200
                  Re: encryption Brian <ad44@cityscape.co.uk> - 2018-04-22 19:10 +0200
        Re: encryption David Christensen <dpchrist@holgerdanske.com> - 2018-04-21 22:50 +0200
      Re: encryption David Christensen <dpchrist@holgerdanske.com> - 2018-04-21 22:10 +0200
        Re: encryption David Wright <deblis@lionunicorn.co.uk> - 2018-04-22 04:00 +0200
          Re: encryption Brian <ad44@cityscape.co.uk> - 2018-04-22 17:40 +0200
            Re: encryption Richard Hector <richard@walnut.gen.nz> - 2018-04-23 08:00 +0200
              Re: encryption Andrew McGlashan <andrew.mcglashan@affinityvision.com.au> - 2018-04-23 09:00 +0200
          Re: encryption David Christensen <dpchrist@holgerdanske.com> - 2018-04-22 20:10 +0200

Page 2 of 2 — ← Prev page 1 [2]

#194947

On 04/21/18 12:10, Brian wrote:
> On Sat 21 Apr 2018 at 13:54:03 -0500, David Wright wrote:
> 
>> On Sat 21 Apr 2018 at 19:14:06 (+0100), Brian wrote:
>>> On Sat 21 Apr 2018 at 11:36:05 -0500, David Wright wrote:
>>>
>>>> On Fri 20 Apr 2018 at 20:38:48 (+0100), Brian wrote:
>>>>> T have a script. It contains an important password.
>>>>
>>>> If you   cat /usr/local/bin/myscript   do you see your important
>>>> password on the screen?
>>>
>>> With the unencrypted file - yes. With the encrypted file -no.
>>>>
>>>>> I have encrypted the script with
>>>>>
>>>>>    scrypt [enc] -t 10 /usr/local/bin/myscript
>>>>>
>>>>> I can, of course, decrypt it with
>>>>>
>>>>>    scrypt dec /usr/local/bin/myscript
>>>>>
>>>>> and then execute the script.
>>>>>
>>>>> The two last steps have been combined into
>>>>>
>>>>>    DECRYPT=$(scrypt dec /usr/local/bin/myscript) && eval "$DECRYPT"
>>>>>
>>>>> Should I have any more concerns with this command than I have with the
>>>>> two-step process?
>>>>
>>>> If so, then won't the password be revealed by ps while eval is
>>>> evaluating it?
>>>
>>> I do not know the most efficacious way to see the ps output in real time
>>> as eval runs. With a bit of trial and error (scrypt is slow enough to
>>> switch to another console and use ps) I captured
>>>
>>> 23266 pts/7    R+     0:00 mpw -q -F     -M                                       -t     railcard
>>>
>>> in its output. mpw is the basic command executed by myscript. Switches
>>> are shown but not parameters. -M is the very important one. The gap
>>> would be occupied by the passphrase.
>>>
>>> Is it possible that ps output does not show parameters to switches?
>>
>> Not AFAIK. Here, I can see lines in the list such as:
> 
> Then I do not understand why paramters are not shown. 

Probably because you did not provide the -f option to ps(1).


When discussing console commands, it is best to cut and paste complete 
console sessions into your post -- prompts, commands entered, and all 
output produced.  Redact sensitive information as needed.


> Maybe they come
> later in the output? I can forsee a few sleepness nights trying to
> figure this out. :)

Type:

$ man ps


See the section 'OUTPUT FORMAT CONTROL'


> At this juncture it appears I should have no worries about ps revealing
> the secret.

Incorrect.  If a password is passed via a command-line option, 'ps -f' 
will reveal the password.


ccrypt(1) provides the -E (--envvar) option for providing the name of an 
environment variable containing the keyword to prevent this vulnerability:

https://manpages.debian.org/stretch/ccrypt/ccrypt.1.en.html

https://packages.debian.org/search?suite=all&section=all&arch=any&searchon=names&keywords=ccrypt


David

[toc] | [prev] | [next] | [standalone]

#194963

On Sat 21 Apr 2018 at 20:10:27 (+0100), Brian wrote:
> On Sat 21 Apr 2018 at 13:54:03 -0500, David Wright wrote:
> 
> > On Sat 21 Apr 2018 at 19:14:06 (+0100), Brian wrote:

> > > Is it possible that ps output does not show parameters to switches?
> > 
> > Not AFAIK. Here, I can see lines in the list such as:
> 
> Then I do not understand why paramters are not shown. Maybe they come
> later in the output? I can forsee a few sleepness nights trying to
> figure this out. :)
> 
> At this juncture it appears I should have no worries about ps revealing
> the secret.

As well as David C's mention of "ps -f" (which was news to me), I should
point out that I use "ps ax" as a matter of course, and "ps wwax" when
when interesting bits fall off the right margin; ie the BSD flavour of ps
gives this information by default.

> >  1247 ?    Ss 0:00 wpa_supplicant -B -i wlp2s0 -c /var/lib/wicd/configurations/44xxfcxxxxxx -Dwext
> >  1706 tty1 S  0:00 xterm -geometry 110x38+0+0 -fn neep-iso10646-1-18 -xrm *Page: 3 1
> > 
> > As you can see, I've mangled the MAC of my router that would be revealed otherwise.
> > 
> > And I wouldn't like to rely on winning a race with ps to avoid capture
> > of information exposed in my command lines.
> 
> I am not after winning any races but (seeing as you brought the issue
> up) knowing whether ps sees my secret and how to go about finding that
> out.

ps might not be the best tool for deliberately finding the info above.
The obvious place to look is /proc/<PID>/cmdline (where NULs separate
the items). One can imagine a scenario where one tries to keep up with
the PID incrementation and hoover up all the cmdlines on the system as
they fly by.

Cheers,
David.

[toc] | [prev] | [next] | [standalone]

#194970

On 2018-04-22, David Wright <deblis@lionunicorn.co.uk> wrote:
>> 
>> I am not after winning any races but (seeing as you brought the issue
>> up) knowing whether ps sees my secret and how to go about finding that
>> out.
>
> ps might not be the best tool for deliberately finding the info above.
> The obvious place to look is /proc/<PID>/cmdline (where NULs separate
> the items). One can imagine a scenario where one tries to keep up with
> the PID incrementation and hoover up all the cmdlines on the system as
> they fly by.
>

There is a mount option to the proc filesystem ('hidepid') that appears
to be designed to harden against the envisioned scenario (if I'm
understanding correctly--may not be the case, though).

https://debian-administration.org/article/702/Hiding_processes_from_other_users

Perhaps this is now obsolete information or something.

Maybe not because in my Stretch man page for proc right at the top
I see the hidepid mount option.

Here (from 2014)

https://lists.debian.org/debian-devel-announce/2014/03/msg00004.html

it is said "* We're planning to request for hidepid to be enabled by
 default (to 1). This will squash an entire class of information leaks. If 
 you have any comments or objections, please get in touch with us.

but I can't seem to discover whether that was realized or not--from what
you people are saying, I guess not (hidepid=1 doesn't appear as a proc
mount option on my upgraded since Methuselah Stretch machine).

Anywho, excuses for the incoherent and perhaps ignorant posting.

-- 
"Three prisoners were locked in a cell. When the largest of them finished his
food, he immediately ate the others. Too bad. An apostrophe in the right place
might have prevented a horrible crime." Joe Gunn

[toc] | [prev] | [next] | [standalone]

#194972

	Hi.

On Sun, Apr 22, 2018 at 09:07:04AM +0000, Curt wrote:
> On 2018-04-22, David Wright <deblis@lionunicorn.co.uk> wrote:
> >> 
> >> I am not after winning any races but (seeing as you brought the issue
> >> up) knowing whether ps sees my secret and how to go about finding that
> >> out.
> >
> > ps might not be the best tool for deliberately finding the info above.
> > The obvious place to look is /proc/<PID>/cmdline (where NULs separate
> > the items). One can imagine a scenario where one tries to keep up with
> > the PID incrementation and hoover up all the cmdlines on the system as
> > they fly by.
> >
> 
> There is a mount option to the proc filesystem ('hidepid') that appears
> to be designed to harden against the envisioned scenario (if I'm
> understanding correctly--may not be the case, though).
> 
> https://debian-administration.org/article/702/Hiding_processes_from_other_users
> 
> Perhaps this is now obsolete information or something.

No, it's slightly outdated (they don't put /proc entry in fstab in
stretch by default), but still useful.


> Maybe not because in my Stretch man page for proc right at the top
> I see the hidepid mount option.

It's in the kernel documentation:

/usr/share/doc/linux-doc-4.9/Documentation/filesystems/proc.txt.gz

and it works:

$ id
uid=1000(user) gid=1000(user) groups=1000(user)...

$ mount | grep proc
proc on /proc type proc (rw,relatime,hidepid=2)
systemd-1 on /proc/sys/fs/binfmt_misc type autofs (rw,relatime,fd=32,pgrp=1,timeout=0,minproto=5,maxproto=5,direct,pipe_ino=8539)
binfmt_misc on /proc/sys/fs/binfmt_misc type binfmt_misc (rw,relatime)

$ ls -d /proc/[0-9]* | wc -l
3


> Here (from 2014)
> 
> https://lists.debian.org/debian-devel-announce/2014/03/msg00004.html
> 
> it is said "* We're planning to request for hidepid to be enabled by
>  default (to 1). This will squash an entire class of information leaks. If 
>  you have any comments or objections, please get in touch with us.
> 
> but I can't seem to discover whether that was realized or not--from what
> you people are saying, I guess not (hidepid=1 doesn't appear as a proc
> mount option on my upgraded since Methuselah Stretch machine).

That's because it's not a default setting. My guess is a certain Modern
Desktop Environment™ breaks somehow if hidepid > 0 is in use. 

Reco

[toc] | [prev] | [next] | [standalone]

#194987

On Sun 22 Apr 2018 at 12:42:04 +0300, Reco wrote:

> On Sun, Apr 22, 2018 at 09:07:04AM +0000, Curt wrote:
> > On 2018-04-22, David Wright <deblis@lionunicorn.co.uk> wrote:
> > >> 
> > >> I am not after winning any races but (seeing as you brought the issue
> > >> up) knowing whether ps sees my secret and how to go about finding that
> > >> out.
> > >
> > > ps might not be the best tool for deliberately finding the info above.
> > > The obvious place to look is /proc/<PID>/cmdline (where NULs separate
> > > the items). One can imagine a scenario where one tries to keep up with
> > > the PID incrementation and hoover up all the cmdlines on the system as
> > > they fly by.
> > >
> > 
> > There is a mount option to the proc filesystem ('hidepid') that appears
> > to be designed to harden against the envisioned scenario (if I'm
> > understanding correctly--may not be the case, though).
> > 
> > https://debian-administration.org/article/702/Hiding_processes_from_other_users
> > 
> > Perhaps this is now obsolete information or something.
> 
> No, it's slightly outdated (they don't put /proc entry in fstab in
> stretch by default), but still useful.
> 
> > Maybe not because in my Stretch man page for proc right at the top
> > I see the hidepid mount option.
> 
> It's in the kernel documentation:
> 
> /usr/share/doc/linux-doc-4.9/Documentation/filesystems/proc.txt.gz
> 
> and it works:
> 
> $ id
> uid=1000(user) gid=1000(user) groups=1000(user)...
> 
> $ mount | grep proc
> proc on /proc type proc (rw,relatime,hidepid=2)
> systemd-1 on /proc/sys/fs/binfmt_misc type autofs (rw,relatime,fd=32,pgrp=1,timeout=0,minproto=5,maxproto=5,direct,pipe_ino=8539)
> binfmt_misc on /proc/sys/fs/binfmt_misc type binfmt_misc (rw,relatime)
> 
> $ ls -d /proc/[0-9]* | wc -l
> 3
> 
> > Here (from 2014)
> > 
> > https://lists.debian.org/debian-devel-announce/2014/03/msg00004.html
> > 
> > it is said "* We're planning to request for hidepid to be enabled by
> >  default (to 1). This will squash an entire class of information leaks. If 
> >  you have any comments or objections, please get in touch with us.
> > 
> > but I can't seem to discover whether that was realized or not--from what
> > you people are saying, I guess not (hidepid=1 doesn't appear as a proc
> > mount option on my upgraded since Methuselah Stretch machine).
> 
> That's because it's not a default setting. My guess is a certain Modern
> Desktop Environment™ breaks somehow if hidepid > 0 is in use. 

Curt's mail was very interesting and well worth posting. Your's is
equally informative. Being able to use hidepid looks like a solution
to  the "... won't the password be revealed by ps while eval is
valuating it?" problem.

However, depending on the system software used, I think it needs a bit
of thinking about. At least, that is what I take away from

 https://bugs.freedesktop.org/show_bug.cgi?id=65575

and

 https://bugzilla.redhat.com/show_bug.cgi?id=1130796

-- 
Brian.

[toc] | [prev] | [next] | [standalone]

#194946

On 04/21/18 11:14, Brian wrote:
> On Sat 21 Apr 2018 at 11:36:05 -0500, David Wright wrote:
>> If so, then won't the password be revealed by ps while eval is
>> evaluating it?
> 
> I do not know the most efficacious way to see the ps output in real time
> as eval runs. With a bit of trial and error (scrypt is slow enough to
> switch to another console and use ps) I captured
> 
> 23266 pts/7    R+     0:00 mpw -q -F     -M                                       -t     railcard
> 
> in its output. mpw is the basic command executed by myscript. Switches
> are shown but not parameters. -M is the very important one. The gap
> would be occupied by the passphrase.
> 
> Is it possible that ps output does not show parameters to switches?

The -f option for ps(1) appears to display options and option values:

2018-04-21 13:47:04 dpchrist@vstretch ~/sandbox/sh
$ cat /etc/debian_version
9.4

2018-04-21 13:47:06 dpchrist@vstretch ~/sandbox/sh
$ uname -a
Linux vstretch 4.9.0-6-amd64 #1 SMP Debian 4.9.82-1+deb9u3 (2018-03-02) 
x86_64 GNU/Linux

2018-04-21 13:47:09 dpchrist@vstretch ~/sandbox/sh
$ cat ps-option-values
perl -e '$| = 1; print "hello\n"; sleep 3; print "world!\n"' &
ps $@

2018-04-21 13:47:11 dpchrist@vstretch ~/sandbox/sh
$ dash ps-option-values -f
hello
UID        PID  PPID  C STIME TTY          TIME CMD
dpchrist  1681  1268  0 11:42 pts/1    00:00:00 -bash
dpchrist  3276  1681  0 13:47 pts/1    00:00:00 dash ps-option-values -f
dpchrist  3277  3276  0 13:47 pts/1    00:00:00 perl -e $| = 1; print 
"hello\n"; sleep 3; print "world!\n"
dpchrist  3278  3276  0 13:47 pts/1    00:00:00 ps -f

2018-04-21 13:47:13 dpchrist@vstretch ~/sandbox/sh
$ world!


2018-04-21 13:47:17 dpchrist@vstretch ~/sandbox/sh
$ bash ps-option-values -f
hello
UID        PID  PPID  C STIME TTY          TIME CMD
dpchrist  1681  1268  0 11:42 pts/1    00:00:00 -bash
dpchrist  3285  1681  0 13:47 pts/1    00:00:00 bash ps-option-values -f
dpchrist  3286  3285  0 13:47 pts/1    00:00:00 perl -e $| = 1; print 
"hello\n"; sleep 3; print "world!\n"
dpchrist  3287  3285  0 13:47 pts/1    00:00:00 ps -f

2018-04-21 13:47:20 dpchrist@vstretch ~/sandbox/sh
$ world!


David

[toc] | [prev] | [next] | [standalone]

#194941

On 04/20/18 12:38, Brian wrote:
> DECRYPT=$(scrypt dec /usr/local/bin/myscript) && eval "$DECRYPT"

On 04/21/18 09:36, David Wright wrote:
> If so, then won't the password be revealed by ps while eval is 
> evaluating it?

Apparently, not:

2018-04-21 13:02:16 dpchrist@vstretch ~/sandbox/sh
$ cat environment-var-ps
CMD="echo hello" && eval "$CMD" && sleep 3 && echo world! &
ps -f

2018-04-21 13:02:18 dpchrist@vstretch ~/sandbox/sh
$ dash environment-var-ps
hello
UID        PID  PPID  C STIME TTY          TIME CMD
dpchrist  1681  1268  0 11:42 pts/1    00:00:00 -bash
dpchrist  2541  1681  0 13:02 pts/1    00:00:00 dash environment-var-ps
dpchrist  2542  2541  0 13:02 pts/1    00:00:00 dash environment-var-ps
dpchrist  2543  2541  0 13:02 pts/1    00:00:00 ps -f
dpchrist  2544  2542  0 13:02 pts/1    00:00:00 sleep 3

2018-04-21 13:02:21 dpchrist@vstretch ~/sandbox/sh
$ world!


2018-04-21 13:03:03 dpchrist@vstretch ~/sandbox/sh
$ bash environment-var-ps
hello
UID        PID  PPID  C STIME TTY          TIME CMD
dpchrist  1681  1268  0 11:42 pts/1    00:00:00 -bash
dpchrist  2556  1681  0 13:03 pts/1    00:00:00 bash environment-var-ps
dpchrist  2557  2556  0 13:03 pts/1    00:00:00 bash environment-var-ps
dpchrist  2558  2556  0 13:03 pts/1    00:00:00 ps -f
dpchrist  2559  2557  0 13:03 pts/1    00:00:00 sleep 3

2018-04-21 13:03:05 dpchrist@vstretch ~/sandbox/sh
$ world!


David

[toc] | [prev] | [next] | [standalone]

#194962

On Sat 21 Apr 2018 at 13:04:20 (-0700), David Christensen wrote:
> On 04/20/18 12:38, Brian wrote:
> >DECRYPT=$(scrypt dec /usr/local/bin/myscript) && eval "$DECRYPT"
> 
> On 04/21/18 09:36, David Wright wrote:
> >If so, then won't the password be revealed by ps while eval is
> >evaluating it?
> 
> Apparently, not:
> 
> 2018-04-21 13:02:16 dpchrist@vstretch ~/sandbox/sh
> $ cat environment-var-ps
> CMD="echo hello" && eval "$CMD" && sleep 3 && echo world! &
> ps -f
> 
> 2018-04-21 13:02:18 dpchrist@vstretch ~/sandbox/sh
> $ dash environment-var-ps
> hello
> UID        PID  PPID  C STIME TTY          TIME CMD
> dpchrist  1681  1268  0 11:42 pts/1    00:00:00 -bash
> dpchrist  2541  1681  0 13:02 pts/1    00:00:00 dash environment-var-ps
> dpchrist  2542  2541  0 13:02 pts/1    00:00:00 dash environment-var-ps
> dpchrist  2543  2541  0 13:02 pts/1    00:00:00 ps -f
> dpchrist  2544  2542  0 13:02 pts/1    00:00:00 sleep 3
> 
> 2018-04-21 13:02:21 dpchrist@vstretch ~/sandbox/sh
> $ world!
> 
> 
> 2018-04-21 13:03:03 dpchrist@vstretch ~/sandbox/sh
> $ bash environment-var-ps
> hello
> UID        PID  PPID  C STIME TTY          TIME CMD
> dpchrist  1681  1268  0 11:42 pts/1    00:00:00 -bash
> dpchrist  2556  1681  0 13:03 pts/1    00:00:00 bash environment-var-ps
> dpchrist  2557  2556  0 13:03 pts/1    00:00:00 bash environment-var-ps
> dpchrist  2558  2556  0 13:03 pts/1    00:00:00 ps -f
> dpchrist  2559  2557  0 13:03 pts/1    00:00:00 sleep 3
> 
> 2018-04-21 13:03:05 dpchrist@vstretch ~/sandbox/sh
> $ world!

That just demonstrates a race between "echo hello" and ps.
Echo won, so all ps saw was the sleep command. What you need in $CMD
is a command that's slow to execute and loses the race:

wren!david 20:52:56 /tmp $ cat testing.sh 
CMD="echo hello && dd bs=1M if=/dev/urandom of=/dev/null count=100" && eval "$CMD" && echo world! &
ps -f
wren!david 20:53:01 /tmp $ bash testing.sh 
hello
UID        PID  PPID  C STIME TTY          TIME CMD
david     1591  1587  0 08:54 pts/4    00:00:00 bash
david    11553  1591  0 20:53 pts/4    00:00:00 bash testing.sh
david    11554 11553  0 20:53 pts/4    00:00:00 bash testing.sh
david    11555 11553  0 20:53 pts/4    00:00:00 ps -f
david    11556 11554  0 20:53 pts/4    00:00:00 dd bs=1M if=/dev/urandom of=/dev/null count=100
wren!david 20:53:04 /tmp $ 100+0 records in
100+0 records out
104857600 bytes (105 MB, 100 MiB) copied, 0.582277 s, 180 MB/s
world!

wren!david 20:53:07 /tmp $ dash testing.sh 
hello
UID        PID  PPID  C STIME TTY          TIME CMD
david     1591  1587  0 08:54 pts/4    00:00:00 bash
david    11562  1591  0 20:53 pts/4    00:00:00 dash testing.sh
david    11563 11562  0 20:53 pts/4    00:00:00 dash testing.sh
david    11564 11562  0 20:53 pts/4    00:00:00 ps -f
david    11565 11563  0 20:53 pts/4    00:00:00 dd bs=1M if=/dev/urandom of=/dev/null count=100
wren!david 20:53:11 /tmp $ 100+0 records in
100+0 records out
104857600 bytes (105 MB, 100 MiB) copied, 0.564181 s, 186 MB/s
world!

wren!david 20:53:12 /tmp $ 

Cheers,
David.

[toc] | [prev] | [next] | [standalone]

#194983

On Sat 21 Apr 2018 at 20:56:43 -0500, David Wright wrote:

> On Sat 21 Apr 2018 at 13:04:20 (-0700), David Christensen wrote:
> > On 04/20/18 12:38, Brian wrote:
> > >DECRYPT=$(scrypt dec /usr/local/bin/myscript) && eval "$DECRYPT"
> > 
> > On 04/21/18 09:36, David Wright wrote:
> > >If so, then won't the password be revealed by ps while eval is
> > >evaluating it?
> > 
> > Apparently, not:
> > 
> > 2018-04-21 13:02:16 dpchrist@vstretch ~/sandbox/sh
> > $ cat environment-var-ps
> > CMD="echo hello" && eval "$CMD" && sleep 3 && echo world! &
> > ps -f
> > 
> > 2018-04-21 13:02:18 dpchrist@vstretch ~/sandbox/sh
> > $ dash environment-var-ps
> > hello
> > UID        PID  PPID  C STIME TTY          TIME CMD
> > dpchrist  1681  1268  0 11:42 pts/1    00:00:00 -bash
> > dpchrist  2541  1681  0 13:02 pts/1    00:00:00 dash environment-var-ps
> > dpchrist  2542  2541  0 13:02 pts/1    00:00:00 dash environment-var-ps
> > dpchrist  2543  2541  0 13:02 pts/1    00:00:00 ps -f
> > dpchrist  2544  2542  0 13:02 pts/1    00:00:00 sleep 3
> > 
> > 2018-04-21 13:02:21 dpchrist@vstretch ~/sandbox/sh
> > $ world!
> > 
> > 
> > 2018-04-21 13:03:03 dpchrist@vstretch ~/sandbox/sh
> > $ bash environment-var-ps
> > hello
> > UID        PID  PPID  C STIME TTY          TIME CMD
> > dpchrist  1681  1268  0 11:42 pts/1    00:00:00 -bash
> > dpchrist  2556  1681  0 13:03 pts/1    00:00:00 bash environment-var-ps
> > dpchrist  2557  2556  0 13:03 pts/1    00:00:00 bash environment-var-ps
> > dpchrist  2558  2556  0 13:03 pts/1    00:00:00 ps -f
> > dpchrist  2559  2557  0 13:03 pts/1    00:00:00 sleep 3
> > 
> > 2018-04-21 13:03:05 dpchrist@vstretch ~/sandbox/sh
> > $ world!
> 
> That just demonstrates a race between "echo hello" and ps.
> Echo won, so all ps saw was the sleep command. What you need in $CMD
> is a command that's slow to execute and loses the race:
> 
> wren!david 20:52:56 /tmp $ cat testing.sh 
> CMD="echo hello && dd bs=1M if=/dev/urandom of=/dev/null count=100" && eval "$CMD" && echo world! &
> ps -f
> wren!david 20:53:01 /tmp $ bash testing.sh 
> hello

[...]

I reduced the contents of myscript to its one essential line:

 mpw -M "secret" "railcard"

Then

 brian@desktop:~$ echo hello && eval /home/brian/myscript && echo world! & sleep 2 && ps -f
 [1] 2049
 hello
 hYM@ei0tSL1rOZRmYD4:
 UID        PID  PPID  C STIME TTY          TIME CMD
 brian     1106  1070  0 14:27 pts/2    00:00:00 -bash
 brian     2049  1106  0 16:15 pts/2    00:00:00 -bash
 brian     2051  2049  0 16:15 pts/2    00:00:00 /bin/bash /home/brian/myscript
 brian     2052  2051 89 16:15 pts/2    00:00:01 mpw -M                                       railcard
 brian     2053  1106  0 16:15 pts/2    00:00:00 ps -f
 brian@desktop:~$ world!

sleep is needed because mpw itself uses scrypt to generate a password
and is slow. -M should be followed by the secret. It is not revealed
by ps while eval is evaluating it. I do not know why. Perhaps it has
something to do with the way mpw processes the command.

-- 
Brian.

[toc] | [prev] | [next] | [standalone]

#194999

[Multipart message — attachments visible in raw view] — view raw

On 23/04/18 03:29, Brian wrote:

> I reduced the contents of myscript to its one essential line:
> 
>  mpw -M "secret" "railcard"
> 
> Then
> 
>  brian@desktop:~$ echo hello && eval /home/brian/myscript && echo world! & sleep 2 && ps -f
>  [1] 2049
>  hello
>  hYM@ei0tSL1rOZRmYD4:
>  UID        PID  PPID  C STIME TTY          TIME CMD
>  brian     1106  1070  0 14:27 pts/2    00:00:00 -bash
>  brian     2049  1106  0 16:15 pts/2    00:00:00 -bash
>  brian     2051  2049  0 16:15 pts/2    00:00:00 /bin/bash /home/brian/myscript
>  brian     2052  2051 89 16:15 pts/2    00:00:01 mpw -M                                       railcard
>  brian     2053  1106  0 16:15 pts/2    00:00:00 ps -f
>  brian@desktop:~$ world!
> 
> sleep is needed because mpw itself uses scrypt to generate a password
> and is slow. -M should be followed by the secret. It is not revealed
> by ps while eval is evaluating it. I do not know why. Perhaps it has
> something to do with the way mpw processes the command.
> 

I believe a program can alter its own command line (as it appears to the
system), and this is done by some programs that take passwords on the
command line - which explains why the password is hidden, but the rest
of the command line isn't. On the other hand, it's generally preferred
not to pass passwords on the command line - use eg a config file, stdin,
or an environment variable instead.

BTW, if you're still interested in the original question, did you find
'shc'? It encrypts your script and creates a binary executable. I don't
know how current/good the encryption is, though. It's in debian.

Richard

[toc] | [prev] | [next] | [standalone]

#195001

[Multipart message — attachments visible in raw view] — view raw

Hi,

On 23/04/18 15:52, Richard Hector wrote:
> BTW, if you're still interested in the original question, did you find
> 'shc'? It encrypts your script and creates a binary executable. I don't
> know how current/good the encryption is, though. It's in debian.

I would say, "not safe enough"....

https://stackoverflow.com/questions/3408373/retrieve-plain-text-script-from-compiled-bash-script

Cheers
A.

[toc] | [prev] | [next] | [standalone]

#194989

On 04/21/18 18:56, David Wright wrote:
> On Sat 21 Apr 2018 at 13:04:20 (-0700), David Christensen wrote:
>> On 04/20/18 12:38, Brian wrote:
>>> DECRYPT=$(scrypt dec /usr/local/bin/myscript) && eval "$DECRYPT"
>>
>> On 04/21/18 09:36, David Wright wrote:
>>> If so, then won't the password be revealed by ps while eval is
>>> evaluating it?
>>
>> Apparently, not: ...
> That just demonstrates a race between "echo hello" and ps.
> Echo won, so all ps saw was the sleep command. What you need in $CMD
> is a command that's slow to execute and loses the race: ...

You're right -- I blew it.


David

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | linux.debian.user

csiph-web