Hi, for the past few months I have been working on my website Installies. It is a site for managing, organizing, and retrieving shell scripts for use to install, remove, update or compile apps on Linux and Unix-based systems.
You might be asking why can’t you just use your system’s built-in package manager. While that will work for most apps there might be some problems with others:
- Some apps might not be on your system’s package manager. This would make it so you might have to compile the app, which might be difficult for newer Linux users.
- Apps you have to run through wine generally are not in package manager’s repositories. They also might need extra libraries that might be complicated to install.
- There might be some weirder software that isn’t really an app, or is not traditionally installed on your computer e.g. TempleOS in a VM.
- Some apps have different packages for similar versions of the app, so a script that lets you choose between all the options would make it easier to decide which one to install, such as QEMU.
As for script security, Installies has a voting and reporting system to help make sure that scripts are safe.
There are some design choices I am yet to make, so I would like your guy’s input. One of them is if app maintainers should be able to stop non-maintainers from creating scripts on apps. Please comment what you think (also any other feedback).
Future Plans
- Utility Scripts: General purpose shell scripts.
- CLI: This will allow for a universal interface to install things on Linux. It will also allow for easier use of Installies on servers.
- Collaboration: Allowing multiple people to directly contribute to scripts without being a maintainer.
- User ranking system: A system to rank users by how popular their scripts. This will make it easier for users to judge if a script is good without having to analyze the source.
As it is in beta, there will be many bugs. If you find any bugs please report them on the GitHub. Feedback and feature requests are also welcome.
Happy Scripting!
Links
You have probably invested a lot of time and effort into this, so please take this as constructive criticism.
Your security systems are probably not going to be sufficient, for a whole number of reasons.
Script Voting
The general public is not able to appropriately audit shell scripts. This extends even to sysadmins and more technical people. The people who can properly audit scripts are a minority, and they may not even be amongst your user base. Anyone who gets a script that “does its job” is going to upvote it as fine, because they may not even be aware of its malicious side effects.
Scripts will naturally need to evolve over time, so script updates will be a normal part of your system. Will the votes reset for new versions? Is there anything stopping someone uploading farming votes with valid scripts, and then backdoor the script once it gets sufficiently popular?
Is there any form of vote manipulation prevention planned? If not, bad actors can create an army of accounts and upvote their malicious content. Can you remove a users votes if they are found to be acting maliciously? Will it even be possible for you to tell the difference between a naive user who doesn’t understand the maliciousness of the script, versus an account actively increasing the rating of a bad package?
User Reputation
This seems easy to game as well. Upload a host of valid scripts, gain reputation, and then when ready, upload malicious scripts.
Collaboration
Allowing non-maintainers to edit and upload scripts seems like a wildly bad idea. There must be some level of maintainer approval for that right? Still will have the same issues, easy for someone to build trust on a script repo and then exploit it when it suits them.
None of these issues are unique to your site, pypi, dockerhub etc have all hit these issues in the past.
I think the only real answer is to have very strong human moderation, but I fear that if your site takes off, the workload will rapidly spiral out of control. Otherwise, interesting idea, Good Luck!
I wholeheartedly agree, yet this is the same for stuff like the AUR, every PPA, or even just blindly copy & pasting inductions from some blog - all of which are very popular. (Just to name some examples that are closer to what op wants to do).
I still wouldn’t use scripts from a random dump site because they are just likely to mess up the os with junk and cruft that will be there forever. But fundamentally from a security point of few its not necessarily worse than what many are doing - simply because it doesn’t get worse than blindly executing stuff from sources missing the reputation to justify trusting them.
Yup, there is a lot of prior art on how to get this wrong :(, and I dont know of any good solutions either. Curation and moderation are probably the best case, but arent bulletproof either.
I raised this not to kill OPs project, but to make sure they go into it eyes open. I personally would be very uncomfortable if my website was being abused to distribute malware, so they deserve to at least be aware of the risks.
I think one puzzle piece of improvement is flatpak:
- It has a verification system, such that users can see which apps are packaged by their developers. For those apps, this eliminates the need to trust a separate maintainer entirely
- It targets almost all linux distributions with a single package. This cuts down the packaging effort for covering the majority of the linux landscape so much, that the number of package maintainers required to be trusted collapses - in the ideal case to just the developers themselves as in the first bullet point
- It makes use of sandboxing, so in case of a malicious app it (in theory) only has access to the stuff the user gave it permission to.
In reality there’s a plethora of problems obviously:
- verified apps are the minority
- some people don’t like the additional storage needed for runtimes (although the more flatpaks you use the more runtimes can be shared and its overall impact gets smaller)
- A lot of apps do not yet use all the portals, and require the classical full access to the system to work properly (in some cases the user can still remove some permission if certain features of the application are not needed by them though). This is just a question of ongoing development work, and hopefully we reach a point in the near future where a flatpak app without tied down permissions raises eyebrows
Thank you for the feedback. I think I will remove the voting system for now while I figure out of solution. I will probably not be adding the user reputation system, unless I figure out a way to do it without facing the problems you have mentioned. As for collaboration, I will add a feature allowing app maintainers to set whether or not non-maintainers can add scripts without maintainer permission. Thank you again for the feedback, it was very useful!
Have you considered some form of CI? I.e: Spin up a VM, run the script, reboot, report what changed? Might be a little expensive, but could help auditing?
I have, but I think it would be a bit too expensive on my VPS, but might use it if my site ever catches on. I have also considered using something like Try, but it isn’t a full sandbox.
Very understandable. And from a security standpoint not necessarily indicitive of anything. A good malicious script would just check its environment first.
Would it know if it was a VM? I think KVMs can host only the kernel if I’m not mistaken
I think you can detect when your in a VM, not sure exactly how though. But they could even be checking for other environment factors, like network addresses, system language, or timezone details.
Maybe add a comment/review system (if you haven’t already) in the meantime? Far from foolproof but better than nothing nonetheless.
It does have a discussion system at the moment where you can comment on a script, but there is no system to rate the script and have the total of all the ratings combined.
If you’re using a shell script to install software, you’ve already failed.
Better alternatives include
- Third-party package managers like Homebrew and Nix.
- Language-specific package managers like pip and npm.
- Self-contained package formats like Flatpak, Snap and AppImage.
- Using checkinstall to turn a package with an install script or a “make install” command into a package your distro recognizes.
- Downloading a tarball and using GNU Stow to install it into /usr/local.
- Compiling from source and installing in $HOME.
The point is not to have the script directly install the program (e.g. getting the binary, putting it where it needs to be, and making a desktop file), but to have the script be used as a wrapper for any of the methods you mentioned above. This would allow for a more consistent installing experience, and in the future, a unified CLI. It would also be better for the reasons mentioned in my post.
OMFG there are so many package managers but you made chocolatey instead…
This thing will simply fail on an alternative filesystem layout, something to be mindful about. For mainstream FHS distro, it’ll work fine.
shell scripts for use to install, remove, update or compile apps on Linux and Unix-based systems
You can probably automatically convert a lot of the Gentoo and nix repos into generic Linux installation and build scripts.
