Scheduled Maintenance: We are aware of an issue with Google, AOL, and Yahoo services as email providers which are blocking new registrations. We are trying to fix the issue and we have several internal and external support tickets in process to resolve the issue. Please see: viewtopic.php?t=158230
MagicPoulp wrote:Can anyone else confirm if dpkg can give total sudo access to the creator of a deb package using post-preinstalled scripts?
Yes, I have several Debian packages in an OBS repository and it would be very simple to add a post-install script to do whatever the hell I wanted to unsuspecting users' systems.
Here is the post-install script from Google's Chrome .deb:
MagicPoulp wrote:Can anyone else confirm if dpkg can give total sudo access to the creator of a deb package using post-preinstalled scripts?
Yes, I have several Debian packages in an OBS repository and it would be very simple to add a post-install script to do whatever the hell I wanted to unsuspecting users' systems.
Here is the post-install script from Google's Chrome .deb:
MagicPoulp wrote:Can anyone else confirm if dpkg can give total sudo access to the creator of a deb package using post-preinstalled scripts?
Yes, I have several Debian packages in an OBS repository and it would be very simple to add a post-install script to do whatever the hell I wanted to unsuspecting users' systems.
Here is the post-install script from Google's Chrome .deb:
I may be wrong again, but it seems to me that for Red Hat distros, the rpm packages have more secure pre/post-install scripts. The different macros seem to give access to certain things, like systemd. One cananot for example put "rm -rf /" in the scriptlet.
MagicPoulp wrote:it seems to me that for Red Hat distros, the rpm packages have more secure pre/post-install scripts. The different macros seem to give access to certain things, like systemd. One cananot for example put "rm -rf /" in the scriptlet.
And systemd unit files can certainly be included (which may also have `rm -rf` as an ExecStart), the scriptlets can then start said unit files to do whatever the packager wants.
Maybe Chromium is save, but why then did it freeze my system like I described in a earlier post? Chrome didn't do that ever, just Firefox and only once.
Maybe Chromium is save, but why then did it freeze my system like I described in a earlier post? Chrome didn't do that ever, just Firefox and only once.
You need to look at the /var/log/syslog
It is good to wait a few minutes before you reboot so you can track the timestamp and the last thing that happens.
How can such a system be considered secured? Whatever package you install can do anything without limitations on your system. Many installations could consist only of copying files.
Maybe Chromium is save, but why then did it freeze my system like I described in a earlier post? Chrome didn't do that ever, just Firefox and only once.
You may be able to mitigate some of this behavior. Under settings Advanced: Disable anything that sends data to Google/Web services, web cam access, microphone access, resolution of navigation errors, payment methods, content settings, and the ability to run background apps when chrome is closed.
The iridium project essentially tries to remove all these features from chromium source.
This is in contrast to, for example, Arch Linux wherein the AUR packages can be installed without any checks at all.
Install scripts or scriptlets are not always used. I don't udnerstand why there is not an option to install packages while disabling install scripts, or making sure no install scripts is used.
On Windows, a program install cannot do whatever it wants ever with root priviledges (UAC). Sorry for the reference to Windows. Maybe I don't understand why it must be the way it is on linux.
debiandonder wrote:My thought exactly! How can one program freeze a whole system in this day and age?
I assume by tying up resources... that happens on my old laptop all the time. Sometimes it's only the browser, other times everything stalls.
That is true and I have had that before. When the browser started acting up and consumed all my 8 gigs of RAM and started to use the SWAP file. Everything slowed down to slow motion. I was able to close the program in the system monitor and everything returned to normal.
The last incident I had was with Chromium 72, latest version in the Debian repository. IT completely froze everything solid. Later I switched to Chrome 73 and no problem.
I am using the latest version of Firefox 65 now and so far so good.
MagicPoulp wrote:Install scripts or scriptlets are not always used. I don't udnerstand why there is not an option to install packages while disabling install scripts, or making sure no install scripts is used.
Because any install scripts that are provided are usually necessary for the package to work correctly.
And as I already mentioned systemd unit files can also be used maliciously and will be enabled and started automatically by APT so that wouldn't remove the risk completely.
MagicPoulp wrote:On Windows, a program install cannot do whatever it wants ever with root priviledges (UAC).
That's because Windows users don't have official package repositories from which software can be safely installed so they end up downloading software from random websites, which is *very* risky indeed. And I think most users just click away the UAC crap without even reading it...
MagicPoulp wrote:Maybe I don't understand why it must be the way it is on linux.
Doug Gwyn wrote:UNIX was not designed to stop its users from doing stupid things, as that would also stop them from doing clever things.
Maybe Chromium is save, but why then did it freeze my system like I described in a earlier post? Chrome didn't do that ever, just Firefox and only once.
You may be able to mitigate some of this behavior. Under settings Advanced: Disable anything that sends data to Google/Web services, web cam access, microphone access, resolution of navigation errors, payment methods, content settings, and the ability to run background apps when chrome is closed.
The iridium project essentially tries to remove all these features from chromium source.
You can see from the size of the source why I'm a bit reluctant to burden the OBS with a separate build, but anyone else is welcome to give it a go. It needs a lot of RAM to build, I seem to remember--the OBS uses eight threads by default.