[Gambas-user] su on non english computers

[Tobias Boege]

On Sat, 16 Jan 2021, Bruce Steers wrote:
> Yes i am sure , It works , thanks.  jeesh
> I'd thank you for all you other words but i don't want them. for starters
> my question is about su not sudo.
> 
> could you at least tell me if you type in a terminal..
> su -c "echo 'i like to be a smart arse'"
> 
> what does su ask ?'
> Does it say
> Password:
> In English or is it written in your language?
> 
> that was my question.
> I thought it was a simple question.
> 

The question was simple. The answer is this:

  $ LC_ALL=de_DE.UTF8 su
  Passwort: ^D
  su: Fehler beim Ändern des Authentifizierungstoken

What can you do to work around this? Yes, you can try to find a common
pattern in that prompt in all languages, but that is not very robust.
sudo also supports a -p argument where you can set your own predictable
prompt, but su doesn't. What really works in every case is to *disable*
localization, so you don't have to deal with this problem at all.
This is done by setting the environment variable LC_ALL=C. In Gambas,
for example:

  Exec ["sudo", "make", "install"] For Input Output With ["LC_ALL=C"]

Then all messages will be in English. The "C" locale always exists and
the LC_ALL setting takes precedence over all other settings.

-- 8< -- Tangent goes off here --------------------------------------- 8< --

And while I'm a fan of telling people exactly what they asked for, after
answering I also like to invoke my hard-earned smart arse privileges to
point out why I think the question is misguided.

su and sudo are programs for authentication. The fact that they localize
and by default want to read from a tty means that they really prefer that
a human enter the password. su and sudo usually take in the password and
act upon it very quickly: they can verify it and escalate your rights on
the system without waiting for anything in between. The secret remains in
memory for the shortest time possible, which is good because that pass-
word is the key to everything.

Your approach takes on half the job of authentication and retains that
important secret in the memory of an unprivileged process far longer.
There are at least two alternative approaches:

  - [su/sudo]: ask the user at the beginning of your process to permit
    starting a privileged version of your program, through su or sudo.
    The normal version already running executes most of the build
    instructions on behalf of the user and the privileged version takes
    over for the installation. This requires some form of IPC between
    the two versions. Or require the user to start your process with
    enough privileges and drop them until you need them. (Unfortunately
    I only know how to do this in Gambas using Extern calls to libc.)

  - [sudo]: do the "sudo loop" technique (hinted at by Jussi and implemented
    in e.g. [1]) where you have the user execute a successful sudo command
    at the beginning of your process and then you repeatedly call sudo on
    the same terminal (inside a Gambas Task) to keep the cached sudo creden-
    tials active. Unfortunately, this credential caching appears to be
    subject to system configuration and may not be available; search for
    "credential caching" in `man sudoers`. The good news is that people
    who disable it *want* to be asked for the password again.

In both the above, you keep a privileged process running for later use
instead of storing the ultimate key to privileged processes for later use.
Your program never comes in contact with the precious password at all;
it is always handled by programs designed to handle important passwords.
Both do not have the downside of prompting the user for a password in the
middle of the work.

But ultimately, it's your call. There is no objectively more secure solution
until the threat has been defined. And installing Gambas is already a highly
insecure task if you assume that there is a compromised process running
under your user. In that case, why bother with passwords if you can just
wait until `configure` wrote the Makefile, then overwrite it with malicious
code, and have the user foolishly execute `sudo make install`?

Best,
Tobias

[1] https://github.com/Jguer/yay/blob/next/exec.go#L22

-- 
"There's an old saying: Don't change anything... ever!" -- Mr. Monk