Turns Out That Snaps Are Not Secure In Ubuntu With X11 (softpedia.com) 133
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.
Huh? Snaps? (Score:3, Insightful)
Snaps for apps? What in the fuck
Re: Huh? Snaps? (Score:2)
Re:Huh? Snaps? (Score:4, Funny)
Snaps [wikipedia.org] is very useful when dealing with apps.
Re: (Score:2)
You know, the "only Luddites use snappy apps for apps" stuff?
Was it suppressed by legions of paid {information deleted} trolls?
Re: (Score:1)
> 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?
Re: (Score:1, Funny)
Or Ubuntu. Oh Snap!
--sf
Re: (Score:1)
It is totally trivial to install a keylogger on Ubuntu
Wouldn't it be great if it wasn't, though.
Re: (Score:2)
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
Re: (Score:2)
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
Re: (Score:2)
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 fi
Re: (Score:2)
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?
Re: (Score:2)
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
Re: (Score:2)
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.
Re: So what? (Score:1, Funny)
Re: (Score:2)
If you want real security, you need to run OS X... or better yet, Windows.
Not sure if trolling or serious...
Help me out.
Re: So what? (Score:2)
Re: So what? (Score:1)
Re: (Score:2)
If you have to ask... ;)
Yeah, but remember Poe's law...
Re: So what? (Score:2)
Re: So what? (Score:1)
Re:Misleading (Score:5, Informative)
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).
Re: (Score:2)
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.
Re: (Score:2)
Better summary (Score:5, Informative)
"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.
Re:Better summary (Score:5, Insightful)
The article/blog does _not_ explore if X11's "untrusted client" feature would help.
I did, well, using SSH's one and yes it does help just fine.
To repeat:
xevilteddy does not work if you treat it as an untrusted client.
The fault is with snaps for not marking them as untrusted, not with X11 for allowing trusted clients. In other news, if you run a compositor as trusted then that too can grab all keystrokes. In other other news if you treat the Wayland compositor as trusted it can grab keystrokes too.
Trusted clients can do trusted shit. This is not especially exciting. It is good to know that ubuntu aren't treating snaps as untrusted though. That's bad, but it's the fault of snaps, not the fact that X treats them as trusted when told to.
Re:Better summary (Score:5, Insightful)
+1 THANK YOU. Yet another unfounded attack on X11 to push an agenda. An agenda to push something that isn't necessarily better.
Re: Better summary (Score:2)
...to push an agenda. An agenda to push something that isn't necessarily better.
Well said.
Re: (Score:3)
Guys, I think you're getting the intent of the story wrong. It's not an X11 security problem. It's primarily a PR problem for Ubuntu & secondarily, it's a security problem for snaps.
Ubuntu has been promoting snaps as a more secure way of packaging
https://insights.ubuntu.com/20... [ubuntu.com]
And the research that Matthew Garret has done has demonstrated that the security provided by the snaps framework is not terribly good. So that's a PR problem for Ubuntu if one of the primary features they are advertising is
Re: (Score:2)
Anything that connects to the display (and keyboard and mouse or other SHARED input/output device by implication) needs to be trusted.
That's true in Windows and Linux and Unix and IBM mainframes and on and on.
Oh, and it'll be JUST AS FUCKING TRUE ON WAYLAND - THAT BENIGHTED SOLUTION IN SEARCH OF A PROBLEM.
Guess they'll have to reinvent User Interface Privilege Isolation [blogspot.dk]. Don't hold your breath, though.
Re: (Score:2)
This is unknown ground for me, so I have to ask: how can the client be marked as trusted/untrusted? (I assume that this is not something specific to snaps)
Re:Better summary (Score:4, Informative)
No, it's a general thing with program security. You can mark programs as trusted or untrusted using a variety of mechanisms.
For example, you can run programs as root (very truseted as they get access to everything), as a normal user (moderately trusted: they can't muck up the whole machine, but they can muck up the user), as a guest user (same, but there's nothing much to muck up) and the using various things like cgroups/jails to sandbox it further.
X has a mechanism to say a client is untrusted in which case it's not allowed to mess with windows that it doesn't own. Trusted clients can mess with each other's windows.
Re: (Score:2)
Can you be more specific? What is this mechanism? Is this about something like having access to X magic cookie stored in ~/.Xauthority? Environment variable? Can I mark /usr/bin/firefox as untrusted, but /usr/bin/xterm as trusted?
Re: (Score:2)
Can you be more specific?
X SECURITY extension. The simplest way to access it is to forward X over SSH with the untrusted setting, but that simply sets up the server mechanism.
Re: (Score:2)
Re: (Score:2)
Btw, since the extension is disabled/not present the ssh -X falls back to ssh -Y (untrusted forwarding) on most systems.
Huh interesting. I'm on stock ubuntu 14.04 and my tests showed it prevented xevilteddy from working. I'm not surprised though about GTK, it generally abuses the X protocol quite badly, and gets lots of things wrong. For example GTK programs frequently crash if I restart the system tray program. Skype never does and if you're doing worse than Skype, you fucked up badly!
Re: (Score:2)
Re: links - I just quoted the post. And yes it is from 2008.
Re: (Score:2)
THAT is the simplest way to access X securely, by running remote code??
It's the simplest method in that it's 1 line. You can also ssh to 127.0.0.1 which is not terribly remote as these things go.
There's an awful lot of X11 defenders here, so tell the rest of us why the secure option isn't on by default please.
Same reason that most userland programs aren't by default run in a filesystem and syscall sandbox.
Re: (Score:2)
THAT is the simplest way to access X securely, by running remote code??
It's a one-liner by using SSH to localhost.
The "correct way" is a bit more cumbersome: Use 'xauth' to generate an authorization key with the "untrusted" flag, then tell the untrusted program to use that authorization key with the XAUTHORITY environment variable.
Re: (Score:1)
$ xauth -f .Xauthority-untrusted generate :0 . untrusted
$ XAUTHORITY=.Xauthority-untrusted xterm
Re: (Score:2)
Very interesting. Thank you. It fails on my system with
but I'll certainly investigate further. I guess that can be just my distro.
Re: (Score:2)
Is this a fundamental problem with the packaging system, or because the package creator didn't set the appropriate options? Would it be solved by having snap have a default setting of untrusted?
The OS will be protected from it anyway... (Score:3)
...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.
Re: (Score:2)
False, snaps are not "meant for running in a container". Isolation (both from other snaps and to keep control over which devices and resources it can access) is achieved via other mechanisms, such as apparmor restrictions. Also, the entire snap is packaged as a squashfs, and all snaps are simply mounted read-only, so they can't modify each other's (or even their own) packaged files.
Snaps also have access to a per-snap writable directory for user and runtime data, but again, they can't even see other snaps'
Even Better Summary (Score:2)
Re: (Score:2)
I think they created them for M$ - and the new WinBuntu mess. (Likely an attempt to start milking software patents - government involvement? - they are a cartel. )
The big point is using them will reduce the polish rate of software. When every package uses the different lib versions - software that depends on lib bugs don't get fixed. And the libs don't get updated - resulting in less secure systems etc.
We don't really want bugs that depend on other bugs -- snap will reduce the long term quality of code.
woah, just a minute (Score:5, Insightful)
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.
Re: (Score:2)
I have been able to run standard apps in user land forever, this is NOT something new. you can easily compile and run an app in the restricted user directory as an X11 app and it cant go digging through the rest of the system.
the hostile app can trash the user directly or try and fake them into giving it escalated privileges but absolutely anything that can display something on the screen or have read/write to the users directory can do that.
Re: (Score:2)
naturally, but this is about the packaging. If you install a deb with sudo then you are running executable code that lives inside the deb with root privileges. With snap installation there is no postinst script or anything that runs as root as part of the install. You might run the snap installer as root, and that might process some commands in the snap, but it isn't running arbitrary code as root I think.
Re: (Score:2)
With a statically compiled binary there is nothing to install. a single file that when launched does everything it needs and has everything it needs, eliminating the dependency hell that linux still suffers badly from.
Honestly I still don't see any real reason for these.
Re: (Score:3)
I agree. Containers essentially have the same properties of statically compiled binaries. The reason they exist is that you can just put existing stuff in there easily without having to refactor. There are just another rotation of the wheel of software complexity (you nicely separate stuff, then you add a lots of interfaces because things need to interact, then you end up having a mess so you create another higher level of separation, etc.)
Re: (Score:2)
Good point.
Re: (Score:2)
I always wanted a "secure deb" format which does not run maintainer scripts and only allows files to be installed in certain directories. Together with reproducible builds this could solve this problem. Containers are not great it terms of security because you risk having all the duplicated libraries. There are reasons people invented advanced packaging formats and those reasons do not simply go away now containers are the new hype...
Re: (Score:2)
Sorry but not in the slightest. If you don't have root access to the system you can only compile and run an app in the restricted user directory if you have the explicit blessing of a sys-admin who has done all the wonderful pre-work of ensuring you have all necessary libraries available for you. Beyond that you're SOL.
Re: (Score:2)
You can always set up a local chroot environment with all necessary dependencies. Sounds difficult? For stuff which is properly packaged, there are fully automatic systems which do this for you... No root required.
Re: (Score:2)
Sounds difficult?
... we're talking about installing a frigging program. If you can't double click the damn thing and call it a day then yes, definitely too difficult.
http://howfuckedismydatabase.c... [howfuckedi...tabase.com]
Re: (Score:2)
I answered to your claim that you need a sysadmin to locally install software. This is not true. I am not sure if somebody made it double-clickable for idiots, but it would be easy to do without inventing a new package format.
Not quite that simple. (Score:5, Insightful)
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.
Re: (Score:2)
Ah thanks, that was the incantation I was looking for.
Re: (Score:1)
Re: (Score:2)
Wouldn't it be a problem If xevilteddy simply changed the environment? Or launched another process without this environment variable?
If I understand xauth correctly, the answer is yes, assuming xevilteddy could find another file containing trusted xauthority credentials. (For example, the original .Xauthority file.) I suggest isolating xevilteddy in a container (LXC), and not putting the trusted credentials in that container.
Re: (Score:2)
Also keep in mind that having an untrusted cookie in an .Xauthority file won't restrict an application that has full display access via xhost, as they do by default on distributions like Ubuntu.
Re: (Score:2)
Wouldn't it be a problem If xevilteddy simply changed the environment? Or launched another process without this environment variable?
No, because this is about snaps, which are containerised and sandboxed. It would have to exploit another hole to break out of the container and get at the trusted .xauthority file.
Is snaps secure with anything? (Score:2)
Honestly this sounds like Snaps in general are horribly insecure on their own.
I don't see the big deal (Score:5, Informative)
Re: (Score:3, Insightful)
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.
Why do you believe this to be true? 16.04 doesn't use Mir and is an LTS, people will be using it for years, and it is not even guaranteed yet that 16.10 will use Mir by default.
Re: (Score:2)
Re: (Score:2)
Since, as you said, 16.04 is LTS, that means that the .DEB packages which are in place now aren't going anywhere. The only packages that currently exist in Snappy Core are enterprise server things.
I don't understand the relevance of your comment. 16.04 supports Snaps, uses X by default, and will be around long enough that snaps will be available for people to download and use within its lifetime, right? If that statement is true, then there is a security risk.
Except Mir == Wayland (Score:1)
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?"
Re: (Score:2)
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?"
I don't think you know what you're talking about.
Except Mir == Wayland (Score:2)
And Wayland has the same feature... No, bug... No, feature!! IT'S INSECURE AAAAAHHHHH!
Re: (Score:2)
If you run Ubuntu Server, you're not using X.org.
Oh that's news to me, given you can add Xorg just like any other package. Why the assumption that every Ubuntu server doesn't have a GUI? There's even manual pages specifically for Ubuntu Server dedicated to telling you the *various* ways you can install Xorg on an Ubuntu server and comes with a nice list of packages that help administer servers via a GUI, and that Xorg and associated libraries get the same length of support in the LTS release as the other packages do.
Someone please help me with this (Score:2)
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.)
Re: (Score:2)
X11 programs can see other programs' events.
By default, yes, but not if they're not authorised.
That's even true if I install the program from a .deb or a tarball, no?
Yes, certainly.
So WTF does this problem have to do with a package format?
Well, the packages are supposed to be for sandboxed stuff, as far as I can tell, so you can run them without risking compromising your machine. It's a pretty poor sandbox if it blithely gives X11 access to the programs at the most trusted level, as opposed to running them
Awwww snaaaaaap! (Score:2)
Seriously, i don't know what motivates Canonical to reinvent the package manager.
Re: (Score:2)
I think Ubuntu Touch [wikipedia.org] motivated this.
Re: (Score:2)
Oh, a mobile OS! That is sure to end up well!
Re: So much for Open SORES (Score:2)
Re: (Score:1)
Re: (Score:2, Offtopic)
Re: (Score:2)
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...
Re:slashdot's ubuntu coverage (Score:4, Interesting)
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.
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)