We're having some issues running our Electron-based app on Debian 10 as it uses Chrome runtime, Chrome requires its sandbox to run and, on defaults, Chrome sandbox won't run on Debian.
Surely, basic solution would be to run without sandbox on Debian, but that option has massive security risks that I'm not comfortable with.
There are other options. The one described in Electron docs and oh so many tutorials is enabling kernel.unprivileged_userns_clone flag:
echo kernel.unprivileged_userns_clone = 1 | sudo tee /etc/sysctl.d/00-local-userns.conf
Supposedly that how it works on other desktop distributions, like Ubuntu. Yet there still are security risks that I just don't fully understand. So far I've found several relevant discussions:
https://lwn.net/Articles/673597/
https://forum.mxlinux.org/viewtopic.php?t=54591
But I'm failing to grasp what exactly is the tradeoff here. How does enabling unprivileged_userns_clone affect security? What are these risks exactly? Are there better options to run Chrome sandbox on Debian securely (as we are stuck with it)?
Related
I've written a Chrome extension and companion native messaging host. I don't have any issues with it failing to start or crashing, but I would like to be able to restart it for updates of the extension. I can't find anything in the documentation or elsewhere regarding this. Is it even possible, or does the browser need to be restarted? Due to the nature of the extension, I'd like to avoid restarting the browser if possible.
Documentation can be found here, but it's not exactly robust.
https://developer.chrome.com/extensions/nativeMessaging
Upon further investigation I have found that restarting the native host application manually is not required. Chrome does this itself on update of the extension. However, that breaks the ability to send messages to the native host application from content scripts that have already been loaded, which was causing the issue I was seeing. Pages can be reloaded to fix messaging.
I am trying to launch game locally, but i have some problems.
Sources seems to be ok , down from github.
Here is one of these mistakes.
Cross origin requests are only supported for protocol schemes: http, data, chrome, chrome-extension, https, chrome-extension-resource.
Okay, thanks for the link to GitHub, I pulled the game down and reproduced the error. It seems strange to me that you wouldn't be able to get .gifs and .wavs when running locally, but there are legitimate security concerns with cross orgin requests, which is why most browsers are so locked down.
Luckily, there is a fairly simple solution to this problem, which I was able to confirm, at least on my end. It does involve running a server, but fortunately the basic Python library provides us with a very easy way to do run a local server. If you already have Python installed, you're ready to go, otherwise, go here: https://www.python.org/download/releases/2.7/
With python installed, its as easy as navigating to the folder containing your index.html file (like FlappyZozio-master) in your command prompt, and typing the following command:
python -m SimpleHTTPServer
Then you can access your game at the url: localhost:8000
There are other ways to set up local servers, as QUIPHOP mentioned, there's node for example. But I find Python to be easiest for quick testing purposes.
Seems like You haven't installed your game on the server. This is required for Phaser
Chrome seems to have released an update over the past week. This has caused at least 50 of our internal applications to throw the exception shown below. The solutions I have researched over the Internet, talk about updating the application server with a stronger cipher. However, our applications are spread out over IIS, tomcat, jboss, weblogic and websphere. Its not practical to expect all of these application servers to be updated. Is there no way to get Chrome to allow an "exception" for these sites ? Since these sites are all internal, the security is not really a concern.
Apparently, Firefox throws the same exception but there is a documented fix for that (by changing some settings in Firefox). Is anyone aware of a similar fix in Chrome.
Error
Server has a weak ephemeral Diffie-Hellman public key
ERR_SSL_WEAK_SERVER_EPHEMERAL_DH_KEY
I found a temporary workaround that should disable the security check in Chrome that is causing that error. It goes without saying that you do NOT want to use this while browsing the open web.
Try adding the following command argument to Chrome when you start it up:
--cipher-suite-blacklist=0x0088,0x0087,0x0039,0x0038,0x0044,0x0045,0x0066,0x0032,0x0033,0x0016,0x0013
I found this solution at this google forum post. Hopefully it will help!
While Maximillian's workaround might work for you at the moment, there is no supported way to add an exception.
The only safe solution is to upgrade the servers, and a less fragile workaround might be to put better proxies right in front of some of the servers.
This problem I found because of the JDK version running on App Server.
If your weblogic/apache server running on java JRockit version "1.6.0_33" & "1.6.0_45" or below you will face this issue.
A solution is to upgrade java to higher version like "1.6.0_101" and higher and restart app server.
I've solved this problem without upgrading jrockit but configuring the ssl section like this
<ssl>
<enabled>true</enabled>
<hostname-verifier xsi:nil="true"></hostname-verifier>
<hostname-verification-ignored>false</hostname-verification-ignored>
<export-key-lifespan>500</export-key-lifespan>
<client-certificate-enforced>false</client-certificate-enforced>
<two-way-ssl-enabled>false</two-way-ssl-enabled>
<ssl-rejection-logging-enabled>true</ssl-rejection-logging-enabled>
<inbound-certificate-validation>BuiltinSSLValidationOnly</inbound-certificate-validation>
<outbound-certificate-validation>BuiltinSSLValidationOnly</outbound-certificate-validation>
<allow-unencrypted-null-cipher>false</allow-unencrypted-null-cipher>
<use-server-certs>false</use-server-certs>
<jsse-enabled>true</jsse-enabled>
</ssl>
Can't tell you exactly whats makes the difference but it solved many different problems on SSL with chrome
Chrome stopped support for NPAPI. We are using plug-ins that used NPAPI to run cmd commands from web browser but now its not working on chrome.
I want to know if there are any alternatives to NPAPI for opening windows cmd or communicating with windows file system from client browser.
First, this is a really bad idea. A really bad idea. I really hope you mean that it was used to execute very specific applications, and not just arbitrary commands.
Second, FireBreath2 is in the works (firebreath's refactor branch) and uses native messaging on chrome to allow things similar to what many plugins did, including this application. Please don't use it to do bad things.
I have read about the advantages of using a BitNami stack for LAMP development, now I am wondering if there are any drawbacks to using BitNami vs manually installing PHP, MySQL, and Apache separately. I use Mac OS but I would be interested on how it applies to both Mac and Windows. Any thoughts?
I am one of the developers of BitNami. Whether to use a native stack or a BitNami stack depends on what you are trying to do. Installing the individual items separately should be exactly the same as running our installer, and the whole purpose why we put the installers together is so you would not have to :) In the case of Mac, one of the advantages of BitNami is that you can have more up-to-date components and multiple installations. A disadvantage / difference is that the applications and path will be different than the typical ones so if you are using third-party tutorials or documentation, it may not work right away
There are 3 common drawbacks to Bitnami vs. a native LEMP/LAMP stack:
File paths. Because Bitnami is a container approach to web stacks, it installs everything in Ubuntu (or whatever Linux distro) under the /opt/bitnami directory. So, many developers who are used to customizing their stack using nano or vim editors (via the Bash shell) quickly discover that you first have to figure out where all the different configuration files of your stack modules reside, etc. Even after you figure those out, most of the online tutorials and documentations you might find will not apply to your stack.
Lockdown. This could be seen as either an advantage or a disadvantage, depending on your perspective (and situation). The entire point of using a containerized approach is to have more control of the stack environment, which can improve compatibility, predictability, security, and otherwise. However as #team-life mentioned, this can quickly become frustrating when you are trying to use "standard" Bash shell commands or even the MySQL CLI, e.g. when trying to analyze or replicate your stack, etc. To put it simply, logging into shell on a server where Bitnami is installed is not in fact logging into the actual shell :)
Upgrades. At the end of the day, Bitnami (and other containers, like Docker) are adding another "layer" to your stack, and thus, more bloat. For some users this "bloat" is justifiable, and preferable (for example, very large companies who require across-the-board uniformity). But what many developers discover with Bitnami and containers is upgrading your stack can be rather janky. For all the alleged advantages in terms of environment "stability", it turns out that upgrading your stack can actually introduce quite a bit of instability and unpredictability, often to the extent of canceling out the benefits. As #domi mentioned, all upgrades run through Bitnami (and not Ubuntu mirrors, etc) meaning you are bound to their versions and release schedules; you are also often required to completely re-install the stack again...
Ultimately, containers are a recent trend that have become very popular among so-called "enterprise" and "corporate" in-house teams, but it is one of those things that might not be the best features for smaller agencies or independent developers to embrace.
That is why native LEMP stacks like SlickStack (my project) are gaining momentum.
This Reddit thread has a few other AWS-specific comments as well.
BitNami uses paths that will be very different from the industry standard ones so if you are trying to login to a server to do some task, it will take you a lot of time to understand their custom-made-folder-structure. And that's a big drawback. When you login to a unix server, you know where the files and paths are, maybe you have one or two options, that are standard. BitNami uses a completely different one. Chaos ensues.
I'm a happy bitnami stack user. It's a great stack. I can describe many advantages.
The draw back of using bitnami stack is the update cycle. For example on Debian/Ubuntu based system, you can not use the standard apt-get update/upgrade.
That means some security updates might not get to your system as fast as your standard cron (automated periodic) update mechanism.
To upgrade the system you will need to create backup, install a new stack, then import the backup to the new stack. Which might not be an ideal procedure.
Some people categorize that as non-production-environment.
Bitnami - ease of use, validated components - known working good configuration.
Disadvantage - Patches and updates. you cannot update packages for security like you can for native install. Any bulletins must be addressed by the bitnami team, who may/will roll out an update to address issues. The bitnami updates are full stack upgrades, meaning you can't just upgrade a single component (php for example) - you need to upgrade the whole bitnami stack, and the often recommended method is to backup your application database, install a parallel bitnami stack that has the latest updates, then restore or migrate to the new installation.
Some will tell you that you can shoehorn patches into bitnami stacks, but it's not at all recommended, will lead you off the stack and most likely cause you down stream issues.
Bitnami evidently is unable to use certain commands from their mysql command line. I'm finding this very frustrating. Here is some stuff I found out.
It puts you into its own bash shell bash-4.2#
mysql>SHOW MASTER STATUS returns -> (nothing) doesn't seem to work
rcmysql start or stop doesn't work from mysql> you have to shell out of where your at and run the ctlscript.sh which is a pain.
Just to get to command line you have to run ./use_lampstack
I'm guessing that they are giving us a very paired down mysql group of commands because there will be less for them to support and less for people to jack up.
So this came up for me because I was trying setup replication. I was following directions from someone who had a "regular" install. It was difficult to follow because most of the commands he was suggesting didn't work from the bitnami mysql> command line. So while I really like the uniformity of Bitnami and the modular nature of it I have run into a snag trying to setup replication.