Slashdot Mirror
Turns Out That Snaps Are Not Secure In Ubuntu With X11 (softpedia.com)
prisoninmate quotes a report from Softpedia: According to Matthew Garrett, a renowned CoreOS security developer, and Linux kernel contributor, Canonical's new snap package format is not secure at all when it is used under X.Org Server (X Window System), which, for now, it is still the default display server of the Ubuntu 16.04 LTS (Xenial Xerus) operating system. The fact of the matter is that X11's old design is well-known for being insecure, and Matthew Garrett took the time to demonstrate this by writing a simple snap package that can steal data from any other X11 software, in this case anything you type on the Mozilla Firefox web browser. As more developers will provide snaps for their apps, Canonical needs to do something about the security of snaps in Ubuntu when using X11 or switch to the Mir display server. In the meantime, the security of snaps remains unaffected for the Ubuntu Server operating system, which is usually used without a display server. Canonical has officially released Ubuntu 16.04 LTS, which is now available to download for those interested.
Snaps for apps? What in the fuck
> A program on a computer can access the data of another program on the same computer?
You do everythng as root? Or you still on DOS?
"snaps" is a new package format for applications on Ubuntu. It is basically a package with dependencies, bundled together and meant for running in a container (docker or lxc I suppose?) which means that the OS is protected from it.
However, since the application has access to X11 window server it has access to the facilities in it including monitoring keystrokes and mouse gestures sent to other X11 applications. So essentially a "snaps" can be a trojan keylogger.
The article/blog does _not_ explore if X11's "untrusted client" feature would help.
If you have some software in a deb, and put that software in a snap, then you have increased your security slightly, but not much. If that software is then put on a Wayland or Mir desktop then you have increased the isolation of it a lot. .deb then you ran it's installation script as root. If it was bad then you are toast already.
If your software is in a
Snaps can be installed without being root, into the user home directory. This is an increased level of ability to run untrustworthy software. This whole exercise is so that open source systems can run untrustworthy proprietary paid for apps without the untrustworthy apps being a huge risk to the peer-reviewed code and other proprietary apps.
Snaps are *not* a step backwards, but they don't get all the way to the end goal by themselves. They may have been over-sold slightly by Canonical because they are mainly for the phone which runs Mir, plus things like Firefox on the desktop which are trustworthy.
Or Ubuntu. Oh Snap!
--sf
Does XEvilTeddy still work over an SSH connection with ssh -X instead of ssh -Y? If not, then the problem is rather easily solvable, and the means to solve it have been there for years.
Let me check...
git clone configure make autoconf apt-get install blah blah oh wow a separate package for xtest wow you managed to save posivily kilobytes for the 0 people who would install x11-dev but not xtest-dev blah blah make oh ffs it needs to be installed this is annoying. Oh hey didn't check your code paths, build build blah
DONE!
OK...
ssh 127.0.0.1 -o 'ForwardX11Trusted no'
aaaand...
Oh look it doesn't work.
So no, X11 is, yet again not fundementally broken. It has a "default allow" policy, but mechanisms have existed for decades to add security to it. The main failing for ubuntu was not enabling the long-established security protections.
SJW n. One who posts facts.
It is totally trivial to install a keylogger on Ubuntu
Wouldn't it be great if it wasn't, though.
Wouldn't it be great if it wasn't, though.
Kind of hard to make it nontrivial though:
sudo dkpg -i ~/Downloads/kernel-keylogger.deb
SJW n. One who posts facts.
...so long as its not running as root. That is kind of the whole point of OS's with user priviledge levels, file system permissions and protected virtual memory. Thats not what containers are for. I could explain but just go google FFS.
You are right, too many Ubuntu stories. We need to go back to the Apple vs FBI Mortal Kombat stories!
Support your local school shooter, give them your firearms.
Honestly this sounds like Snaps in general are horribly insecure on their own.
Do not look at laser with remaining good eye.
But it is. If you want real security, you need to run OS X... or better yet, Windows.
If you want real security, you need to run OS X... or better yet, Windows.
Not sure if trolling or serious...
Help me out.
SJW n. One who posts facts.
Don't feed the shills so nicely and politely; it works better if you cram the shit down their throats with the equivalent of the butt-end of an iron-banded oaken staff.
If you have to ask... ;)
If you run Ubuntu Server, you're not using X.org. If you're running Ubuntu 16.04 on the desktop, you're probably not using any snap packages (except maybe Firefox). By the time desktop applications start to be packaged in snappy form, Ubuntu will be using Mir as the display server instead of X.org.
If you have to ask... ;)
Yeah, but remember Poe's law...
SJW n. One who posts facts.
Well it was downmodded due to being an outright lie. There is no known problem with the MySQL unit file in Ubuntu 16.04 LTS, in fact it's very straight forward as compared with the horrible mess the System V init file for MySQL was.
I may be the smartest dumb person ever; in any case, I had to look that up...
X11 is not fundamentally insecure. In fact, X11 had the security infrastructure to shield clients from each other for a long time. It is just not used and also has been neglected (people did not fix the bugs in applications which I filed - so some applications do not run as untrusted clients). The reason for this is that there was almost no point using it before, because different processes of the same user are not shielded against each other on Linux anyway, so there is nothing gained by doing it at the X level (maybe there is now with containers - although this is the wrong approach: containers are a security nightmare because the duplicate all library code). With respect to clients/processes of the same user, X is fundamentally much more secure than Linux has ever been - because at least in principle it had the infrastructure to protect clients from each other (although rudimentary and neglected).
And Wayland does the same thing.
Not to mention the simple fact probably the #1 question for Ubuntu Server is "How do I install a GUI?"
And Wayland has the same feature... No, bug... No, feature!! IT'S INSECURE AAAAAHHHHH!
http://www.maxineudall.com/2010/02/should-economists-be-sued-for-malpractice.html
Surely it couldn't be that hard to fix. As I understand it, the only reason to let applications grab events from other applications is to allow global hotkeys to be implemented. If that's the case, then don't send alphanumeric keys to other applications, unless accompanied with a modifier other than Shift or AltGr.
Snaps are Ubuntu's desperate attempt to be trendy and cool like those new kids with the phones and tablets.
Sure.
As I understand it though, one of the selling points of Snaps is that they are much more sandboxed than traditional packages, so that you don't have to worry about them as much - install keylogger.snap (or whatever), and it can only log keystrokes intentionally sent to it. At least if you're not running X11.
Frankly I think it's a long overdue move, that keyloggers even exist on any platform is evidence that inter-application security has been atrocious for a long time. User based security is nice and all, but is pretty much pointless on a single-user machine.
--- Most topics have many sides worth arguing, allow me to take one opposite you.
X11 programs can see other programs' events. That's even true if I install the program from a .deb or a tarball, no? So WTF does this problem have to do with a package format?
(Oh, and if calling me ignorant/lazy or saying LMGTFY helps you explain it, fine. I'll take your assholiness as long as you have answers.)
As copyright owner of this comment, I authorize everyone to defeat any technological measure which limits access to it.
AFAICT, snaps is no worse in this regard than any other packaging system out there: dpkg, rpm, pacman, etc. Am I right? Is all this fuss about the claim of better-but-not-actually-perfect sandboxing? Admittedly there is this gaping hole in X11 security (the way it's implemented in any case), which has been around for decades. But the article makes it sound like snaps are a new kind of bad. I don't think that's true, but hopefully some slashdotter will set me straight.
Valid, sure. Just mostly pointless, because how many people actually run their web browser as a different user? Yeah, it makes it much easier to keep malware from tampering with system processes, etc, but that doesn't really gain you much - oh great, the malware can't touch my OS, all it can do is monitor everything I do and access all my personal files. I feel so much safer.
Well, okay, I suppose it's nice that you don't have to worry about things like the old class of viruses where opening an infected file in Word would infect the executable, which would then infect all future files you opened. But that's still like plugging one hole in a sieve.
Personally I would love to see a One Laptop Per Child style per-app, per-functionality permissions system showing up in desktop OSes. Android sort of does it, except then they went and grouped permissions into huge lumps of unrelated permissions, and then only inform you of the required lump permissions, rather than giving you the option to simply deny access. I'm hoping the day will come when it's normal for each application to have an OS-controlled permissions screen with checkboxes beside all the permissions it requests, and app-supplied explanations of what functionality each permission is required for. Lets stop with this all-or-nothing trust model.
--- Most topics have many sides worth arguing, allow me to take one opposite you.
Valid, sure. Just mostly pointless, because how many people actually run their web browser as a different user?
...
I'm hoping the day will come when it's normal for each application to have an OS-controlled permissions screen with checkboxes beside all the permissions it requests, and app-supplied explanations of what functionality each permission is required for.
Seriously? You think it's too much work to run a browser as a different user, but you think anyone will bother to review every individual permission buried in a per-app config setting, and re-verify on every update?
WHY would the init script for MySQL need to be a mess? Just what is it doing that's terribly complex or the least bit subtle?
Neither variant should be that interesting actually...
A Pirate and a Puritan look the same on a balance sheet.
Those who care? Yes. And for the rest you can highlight the most questionable access permissions: network, webcam, non-sandboxed file system, etc. Maybe even include groups of actually related permissions that can be granted/denied en masse for convenience, just allow users to also change them individually when necessary. Heck, you could even have a default profile governing the permissions granted to all applications in the absence of application-specific settings. Then the user only needs to decide if a particular application should get any special treatment.
Why would you re-verify permissions for an update? Updates should default to keeping the same permissions the previous version had, only if it asks for new permissions not previously either granted or denied, do you need to ask the user which of those new permissions to allow.
If you're feeling particularly security conscious you could even add an "ask every time" permission setting - just because I occasionally want to use my webcam through my browser, doesn't mean I want anything that hijacks my browser at any time to have that access.
--- Most topics have many sides worth arguing, allow me to take one opposite you.
Seriously, i don't know what motivates Canonical to reinvent the package manager.
The security mechanism isn't complicated at all. In fact, it is probably too simply. I explained why it is not used: because processes of the same user can already spy and manipulate each other anyway.
In all seriousness, if you want security, run ChromeOS. There's a chain of trust that starts from the Trusted Platform Module. Basically Verified Boot makes sure that someone hasn't modified the system code. And then for other applications, they have to run in a sandbox like NaCL or the pepper plugins. NaCl allows ChromeOS to run native code, but it doesn't have direct access to the OS.
Because System V init does not do process monitoring and service restart upon crash the MySQL people decided to write their own work around using shell scripts, this is why you can see a mysqld_safe process running as well as the regular mysqld on non systemd systems. mysqld_safe is a 1117 line bash script and /etc/init.d/mysql (the System V init script for MySQL) is a further 197 lines of bash:
root@sql:~# wc /usr/bin/mysqld_safe /usr/bin/mysqld_safe /etc/init.d/mysql /etc/init.d/mysql
1117 4059 31801
root@sql:~# wc
197 777 5742
Since this monitoring is done by a bash script it's not always 100% safe, I have on several occasions encountered situations where a "service mysql stop" returned with OK but that the mysqld_safe process refused to die, noticed that mysql where stopped and restarted it behind the scenes resulting in upgrades going to complete shit among other things.
Since all that shit is now instead handled properly by systemd due to i.e control groups the unit file for MySQL is extremely simply and straightforward:
# MySQL systemd service file
[Unit]
Description=MySQL Community Server
After=network.target
[Install]
WantedBy=multi-user.target
[Service]
User=mysql
Group=mysql
PermissionsStartOnly=true
ExecStartPre=/usr/share/mysql/mysql-systemd-start pre
ExecStart=/usr/sbin/mysqld
ExecStartPost=/usr/share/mysql/mysql-systemd-start post
TimeoutSec=600
Restart=on-failure
RuntimeDirectory=mysqld
RuntimeDirectoryMode=755
No more mysqld_safe siliness and also everything down to a 20 line unit file that is a hell of a lot easier to parse manually than the old init scripts.
So I do hope that people will now see that the AC:s that keep posting these lies are in fact just lying trolls, not a single one of them have ever read the MySQL unit file and not a single one of them have ever run MySQL on a distribution using systemd.
There are no bug reports where the "problem" with MySQL where fixed because there never where any bug reports that there where any problems in the first place. And this is because there is no problem with the MySQL unit file, and there never was, you just fell for a troll that have posted the same thread of posts to each Linux related article in the latest weeks.
Sorry to rain on your parade but all database servers have this feature. PostgreSQL uses a master provess that restarts the backend processes if they crash. Microsoft SQL Server have a SQL Server Agent that does the very same thing and so on.
I definitely do not like Systemd but there is absolutely nothing wrong with MySql unit files in Ubuntu (typing this on Kubuntu 15.10 with Kubuntu 16.04 running in a vm under virtual box, both the guest and the host have the complete LAMP stack running)...that user was either trolling or had no idea what they were talking about and were rightly buried.