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?
Why is this supposed to bother me?
This is nothing new. X11 is fundamentally insecure. Yes, another application can send input to your xterm that's su'd to root. Nothing new.
i never caught on to the whole docker container/snap package thing anyways. since when did it get so hard to set things up by yourself? also, if your package manager sucks balls, then you need to find a new distro. stop putting up with crap.
"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.
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.
For free software the project can be integrated through distro maintainers and some auditing can go on. At least compiling and testing a more reduced set of versions by a bigger community of users.
I think snap is mostly to make life easier for proprietary application distributors, so they can hide any secrets, avoid integration and maintainers and still get access to users.
So I don't understand why you are taking on open source ?
...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.
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.
What's even worse than the poor choice of submission selection is the censoring that has gone on in the Ubuntu stories. For example, I saw one comment reporting a possible problem with the systemd unit files for MySQL. As a potential Ubuntu and MySQL user, it's important for me to know about possible problems such as that one. Yet that comment was modded down. Even worse than that, somebody (or somebodies) went through and systematically modded down many of the replies to that comment, too!
This release of Ubuntu is an LTS release. Some of us could potentially be using it until 2021. If somebody is having problems with a critical part of this release, then it's important to get the word out. We shouldn't have abusive Slashdot moderators suppressing information that could potentially save people a lot of time. If there are problems with systemd and MySQL in Ubuntu, then we need to know about them.
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.
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.
Apparently, somebody didn't know how to write one...
They are quite simple.
But who in this age of interwebs knows how to write a shell script? It's not Rust nor JSON, so it's not hip. Who's gonna learn something as unhip as sh?
Can you please prove to us that it's an "outright lie"? You'll need to provide something substantive, like bug reports clearly indicating that the problems were fixed, with patches that we can review.
It doesn't matter what software we're talking about. As responsible sysadmins and developers, we have to assume that all bug reports are true until proven otherwise.
Even if you aren't experiencing problems with your particular setup, somebody else with a different setup may be experiencing them. They aren't "lying" when they report a problem that you aren't experiencing!
I follow many Linux distro mailing lists, and I've seen a lot of reports of problems with systemd. It doesn't matter if the Linux distro is Fedora-based or Debian-based, a lot of people have had problems with systemd.
So my instinct is to believe that, when presented with a bug report implicating systemd, that systemd is at fault until proven otherwise. It has been at fault for a lot of other people in many other cases.
I'm glad that I browse Slashdot at -1. Now I know to be far more cautious than usual when dealing with Ubuntu 16.04 LTS thanks to its use of systemd, even if Slashdot mods want to suppress that info.
[Oh, and please don't mod ACs like us off-topic. It's difficult enough to get visibility as a +0 AC already. Thanks!]
Thanks for listening, Mr Mod!
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
So it's an issue that's being addressed, and snaps do provide security for non-graphical apps. It's unfortunate that it's being implied that the security benefits are more universal than they are but it's a subtle point that is difficult to emphasize. When trying to promote a new release, you want to emphasie the new features, not the subtle non-features.
Here's how!
Start gnome-terminal
$ xinput list
Virtual core pointer id=2 [master pointer (3)]
Virtual core XTEST pointer id=4 [slave pointer (2)]
VirtualBox mouse integration id=9 [slave pointer (2)]
ImExPS/2 Generic Explorer Mouse id=11 [slave pointer (2)]
Virtual core keyboard id=3 [master keyboard (2)]
Virtual core XTEST keyboard id=5 [slave keyboard (3)]
Power Button id=6 [slave keyboard (3)]
Sleep Button id=7 [slave keyboard (3)]
Video Bus id=8 [slave keyboard (3)]
AT Translated Set 2 keyboard id=10 [slave keyboard (3)]
Find the id of the keyboard (10 in this case)
$ xinput test 10
open another gnome-terminal
$ sudo ls
[sudo] password for AC:<password>
Watch the scancodes in the first terminal. OMG there's ur password! (for brevity just listing keypress)
key press 39
key press 30
key press 40
key press 32
key press 65
key press 46
key press 39
key press 36
key press 58
key press 44
key press 42
key press 14
key press 18
key press 33
key press 30
key press 28
key press 52
Open a gui app as root
Type something
OMG there's muh typing!
There you have it, your very own keylogger. It works on all systems with X11 because by default nobody locks it down.
Snaps are Ubuntu's desperate attempt to be trendy and cool like those new kids with the phones and tablets.
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.
I blame systend
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.
Seriously, i don't know what motivates Canonical to reinvent the package manager.
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.
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:
...You'd wish they'd spend the effort on fixing their server-crash bugs rather than working around them with a lengthy script.
Ah well, happily MySQL-free here since 2007 or so.
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.