On 2/23/20 11:10 PM, marc wrote:
>>>> You should never send an unencrypted password over a shell or pipe.
>
> So in the case of the former (using the shell, via echo or an
> environment variable) you are correct. Those show up in process
> listings...
>
> I am not so sure about the second part, the bit about not passing
> confidential information down a pipe. I am not aware of a third
> party being able to see the content of a pipe. If you are worried
> about the invoking user seeing the password, bear in mind that on sane
> distributions a normal user can strace the xterm in which one
> invokes su or sudo. This is not a recommendation to disable
> strace, it is a strong recommendation to run your webbrowser
> under a different uid - actually I am surprised that distributions
> dont have a wrapper which runs a browser as a different uid
> but with a shared gid...

Hi,
I intended | as a pipe, so doing echo something |.
>
>> i would use a simple gtk window with a gtkentry (Gtk2 GTK3 compatible) + 2 buttons (cancel, ok)
>> that way it will be the gtk backend to care about X11 or wayland (i suppose...):
> ...
>> Why use 2 binaries rather than one, more programs, more code, more communication in between them equals to more attack surface.
>> I would stay with just one suid binary, more so if you want to go the su-only route.
>
> If I understand you correctly, you propose a simple gtk
> program that is setuid (so that it can read /etc/shadow, and
> grant root privileges). The problem is that there is no such
> thing as a simple gtk program. This is not comment limited to
> gtk programs - most graphical toolkits and libraries present
> a pretty large attack surface - they contain large protocol
> interpreters and font rendering engines, flaws in which could
> then be exploited to give root access without any password
> whatsoever.

Yes, but after having written part of it, it looked to easy
to be true and I started wondering why nobody did it that
way already and so I figured out the reason myself.
I fully agree.

> So invoking su or sudo via a pipe is probably the way to go
> after all. Do note that sudo (or su) might not accept input
> from a plain pipe - you might have to allocate a pseudotty
> via /dev/pts/ptmx, then fork, exec su or sudo in the child
> and in the parent write the password down the filedescriptor...
>
> regards
>
> marc

Ciao,
Tito