Transfer Desktop Settings to new User

Werner Holtfreter · 2017-02-08 23:58

In the meantime I read a bit about the "q4os installer": http://www.q4os.org/dqa009.html. The last sentence:

Upload and publish this file somewhere on the Internet, Q4OS users will be happy for easy setup of your application.

It works like Windows - installation by click in a website. Do it have the same danger? If the author of the self-installing-program can decide the need of password, than it is a security issue in my eyes. If the user can configure the password policy, than it is OK.

Please, who decide this?

Dai_trying · 2017-02-09 00:48

I guess it is like any software that can be downloaded, you must have some trust in the source, otherwise you should not install it. And that applies to any operating system Mac Linux and Windows.

Werner Holtfreter · 2017-02-09 01:10

My question was: Who decide about the password request? I suppose, the programmer (in our case you) for my computer! This is complete unacceptable.

Normally, in a well configured Linux, I can download each file or program without danger for the system integrity. Without the root-password (which can be identically with one user password) it must be impossible to change any root directory or install programs with root privileges.

q4osteam · 2017-02-09 08:44

Werner Holtfreter wrote:

Without the root-password (which can be identically with one user password) it must be impossible to change any root directory or install programs with root privileges.

It is. You need to enter the password at the login time. Other (non privileged / non sudo) users are not allowed to install applications using Q4OS installer.

bin · 2017-02-09 08:48

If you launch the Q4OS software installer and pick a package from that list then the installer does not ask for a password.

If you download a .esh installation package, double click to launch the installation and click Install then I think it can be safely argued that you are agreeing to the installation of that software and what it will do. If Dai's installer asked for a root password would it make any difference to the payload? What if the script was actually sending the root password back to a server somewhere?

If that package contains malicious content then there's not a lot you can do. This is at odds with the model of the repository where - in theory - the packages will have been tested and will have gone through a series of hoops to get there in the first place.

In the good old days the concept was to protect the operating system at all costs, individual user data is secondary - hence the model you describe - which is absolutely fine and correct in a multiuser environment. With desktop linux - especially now it is such a doddle to install - I would argue that the user data is by far and away the more important factor. The biggest danger is people downloading and running executables in their own home directories - Palemoon and others I'm looking at you!

You are already at arguably greater risk if you allow javascript or allow flash-player or use IoT devices in your home. The great thing about linux is that you have a choice - oh and if you break it then you get to keep all the pieces

Werner Holtfreter · 2017-02-10 10:13

q4osteam wrote:

Werner Holtfreter wrote:
Without the root-password (which can be identically with one user password) it must be impossible to change any root directory or install programs with root privileges.
It is. You need to enter the password at the login time. Other (non privileged / non sudo) users are not allowed to install applications using Q4OS installer.

The Unix rule "No normal work as user root." is to protect against myself. It works fine in some cases, all of this comands ask the password:

werner@zuse:~$ sudo -i
[sudo] password for werner:
werner@zuse:~$ sudo synaptic
[sudo] password for werner:

But I can install each program in root directories from each website without password!

That can not be a good security.

q4osteam · 2017-02-10 12:19

@Werner Holtfreter
If you would want to enforce system security, you could set 'sudo' to ask password on every command. Note, you will not be able to use Q4OS installers after this action.

First disable apt permissions:
$ cd /etc/sudoers.d/
$ sudo mv 30_q4os_apt .30_q4os_apt.disabled

Set sudo timeout:
$ sudo visudo -f q4_sudo_confd
edit the line:

Defaults timestamp_timeout=30

and set timeout to '0'

We don't think this action could take a significant effect for the system protection, in accordance to the arguments above. If you would want to make system really hardened, you would have to take a more complex solution, see Security-Enhanced Linux https://en.wikipedia.org/wiki/Security-Enhanced_Linux

Werner Holtfreter · 2017-02-10 12:51

Can anybody write a bit about the principle of the "Q4OS installer" or a link to that?

q4osteam · 2017-02-10 12:57

Q4OS installer just uses 'apt' commands as they are. So, it uses 'apt-get install' to install an application. It is capable to include a local or remote repository and install packages from it using 'apt-get' command, the same way as user in terminal.

Werner Holtfreter · 2017-02-11 17:20

Thanks. The apt commands needs normally password authorization. On which way receive apt the authorization in case of Q4OS installer?

q4osteam · 2017-02-11 18:12

Werner Holtfreter wrote:

The apt commands needs normally password authorization. On which way receive the authorization in case of Q4OS installer?

The authorization could be provided by sudo or policykit. There is '/etc/sudoers.d/30_q4os_apt' configuration file in Q4OS, providing execution permissions of the apt-get and dpkg commands for members of 'sudo' group. So, if you are member of the 'sudo' group you don't need to enter your password for apt-get as well as for running Q4OS installer.

Werner Holtfreter · 2017-02-11 20:33

I hope to have understood: Only the specified commands

/usr/bin/apt-get *
/usr/bin/apt-key *
/usr/bin/dpkg *

are usable without password. The installer-.esh-file includes a shell script, running only with user rights and the install commands of this script are usable without additional rights.

Perhaps no big security issue with a small user group of Q4OS, but nevertheless an open door: A link named tits.pics could be evil.esh which silent installs an evil program! If the Q4OS team prefer this way for installation, this open door should be closed.

I prefer the installation of an additional repository with the system standard tools. So, it exist no need to learn and discuss a new install principle. On this way, the updates come automatically. For example the following great tax return software for small business:

http://www.jes-eur.de/?Repositories:deb-Repository

I fear, a programmer will not do both, the installer script and the repository.

Dai_trying · 2017-02-11 22:49

I guess this will come down to the same thing I said earlier

I wrote:

I guess it is like any software that can be downloaded, you must have some trust in the source, otherwise you should not install it. And that applies to any operating system Mac Linux and Windows.

And in response to

Werner Holtfreter wrote:

A link named tits.pics could be evil.esh which silent installs an evil program!

You still have to confirm to install software (with or without password) and so it could not "silent install"

Werner Holtfreter · 2017-02-11 23:26

Dai_trying wrote:

Werner Holtfreter wrote:
A link named tits.pics could be evil.esh which silent installs an evil program!
You still have to confirm to install software (with or without password) and so it could not "silent install"

Are you sure, it is impossible to write a script for "silent install"?

Dai_trying · 2017-02-11 23:45

The q4os installer routine shows a dialog that you will need to confirm to install, I can not see a way to bypass this ( I do not believe it is possible).
If you think it is possible could you provide some reference or example?

q4osteam · 2017-02-11 23:47

Werner Holtfreter wrote:

I hope to have understood: Only the specified commands ... are usable without password. The installer-.esh-file includes a shell script, running only with user rights and the install commands of this script are usable without additional rights.

Yes, exactly.

Werner Holtfreter wrote:

A link named tits.pics could be evil.esh which silent installs an evil program! If the Q4OS team prefer this way for installation, this open door should be closed.

It's not possible in Q4OS to execute a link 'tits.pics' as .esh file from webbrowser nor from filemanager nor from commandline.

Werner Holtfreter wrote:

If the Q4OS team prefer this way for installation, this open door should be closed.

In any case we will investigate your suggestions carefully. If there is any possibility of security issue, it will be definitely fixed.

Werner Holtfreter wrote:

Are you sure, it is impossible to write a script for "silent install"?

It is possible to write such script ( and it would be worth our attention ), but still the only way to run that script would be to download it first, save, and then wilfully run it from file manager.

q4osteam · 2017-02-12 00:01

Dai_trying wrote:

... could you provide some reference or example?

Just write simple test.esh script:

#!/bin/sh
sudo -n apt-get install some_package

The only way to run that script would be to download it first, save, and then run it from file manager or from commandline.

Werner Holtfreter · 2017-02-12 02:13

I am satisfied now. Thank you very much for the good, helpful explanations of some users and the q4osteam. Thank you also for the best tool which I have seen up to now for backup and restore the desktop settings from Dai_trying.

q4osteam · 2017-02-12 08:37

q4osteam wrote:

It is possible to write such script ...

Well, we have considered it's a potential security issue. We will fix it the following way. Esh scripts will not contain execution code itself, there will be a dedicated wrapper to check esh script first and run a setup window on it's own. So, there will be no way to write a 'silent install' script, as described above, anymore. Any other suggestions ?

@Werner Holtfreter, Dai_trying, bin
Thank you for your helpful and valuable contributions, and suggestions, in this thread.

bin · 2017-02-12 10:40

q4osteam wrote:

q4osteam wrote:
It is possible to write such script ...
Well, we have considered it's a potential security issue. We will fix it the following way. Esh scripts will not contain execution code itself, there will be a dedicated wrapper to check esh script first and run a setup window on it's own. So, there will be no way to write a 'silent install' script, as described above, anymore. Any other suggestions ?
@Werner Holtfreter, Dai_trying, bin
Thank you for your helpful and valuable contributions, and suggestions, in this thread.

Thanks for this team. You may recall in the past I had some concerns about the lifetime of the sudo login. I think what Werner has done is to articulate the sort of problem I had in mind but could not accurately describe - good job!

Werner Holtfreter · 2017-02-12 15:31

bin wrote:

You may recall in the past I had some concerns about the lifetime of the sudo login. I think what Werner has done is to articulate the sort of problem

Yes, all automatics without understanding of user is problematic. Everybody knows the problems with the lot of MS Word automatics: Only helpful if I understand it and know to switching on and off.

The new Q4OS installer should have the same password policy like Synaptic.

Q4OS Forum

#26 2017-02-08 23:58

Re: Transfer Desktop Settings to new User

#27 2017-02-09 00:48

Re: Transfer Desktop Settings to new User

#28 2017-02-09 01:10

Re: Transfer Desktop Settings to new User

#29 2017-02-09 08:44

Re: Transfer Desktop Settings to new User

#30 2017-02-09 08:48

Re: Transfer Desktop Settings to new User

#31 2017-02-10 10:13

Re: Transfer Desktop Settings to new User

#32 2017-02-10 12:19

Re: Transfer Desktop Settings to new User

#33 2017-02-10 12:51

Re: Transfer Desktop Settings to new User

#34 2017-02-10 12:57

Re: Transfer Desktop Settings to new User

#35 2017-02-11 17:20

Re: Transfer Desktop Settings to new User

#36 2017-02-11 18:12

Re: Transfer Desktop Settings to new User

#37 2017-02-11 20:33

Re: Transfer Desktop Settings to new User

#38 2017-02-11 22:49

Re: Transfer Desktop Settings to new User

#39 2017-02-11 23:26

Re: Transfer Desktop Settings to new User

#40 2017-02-11 23:45

Re: Transfer Desktop Settings to new User

#41 2017-02-11 23:47

Re: Transfer Desktop Settings to new User

#42 2017-02-12 00:01

Re: Transfer Desktop Settings to new User

#43 2017-02-12 02:13

Re: Transfer Desktop Settings to new User

#44 2017-02-12 08:37

Re: Transfer Desktop Settings to new User

#45 2017-02-12 10:40

Re: Transfer Desktop Settings to new User

#46 2017-02-12 15:31

Re: Transfer Desktop Settings to new User

Board footer