Hacker News Reader

Comment by viraptor | Hacker News Reader

This is probably a good reminder of something else: using selinux/apparmor/tomoyo/... can save you from many situations where you'd be exploited otherwise. For example as a response to this you can set a policy on lesspipe and all its children so that they cannot access the internet or write outside of temp directories.

Whatever library is used by lesspipe - you're safe as long as the output terminal and your kernel are safe.

View on HN

This is a good point, and I fully endorse the sentiment, but please remember that for basically all modern distros shipping SELinux as default (not counting android), the default is for users to be unconfined.

This means that in a lot of cases, SELinux won't save you from this, unless you've decided to confine your users (which is by no means impossible - I do so - but requires a bit more knowledge of SELinux than "usual" SELinux tasks)

> basically all modern distros shipping SELinux as default.

No on ArchLinux, Gentoo, and apparently, not on Debian.

I also remember that the default settings were not sane on older versions of Fedora (this may have since changed): sshd would get killed by selinux because of some "violation". I never managed to understand what it was, and since sshd is kind of critical, I disabled SELinux so I could be sure not to lose access to that machine.

The added problem regarding SELinux is that most user's have no idea how it works, and there's no "short" explanation for it. Even after reading the entire wikipedia article, I'm left scratching my head wondering how it work or how one would use it.

OTOH, file modes, for example , are explained in a single paragraph, and is something extremely easy to understand.

This should honestly be part of every modern Linux system. It would go a long way toward creating the kind of reasonably secure system people are looking for.

I would envision this to be useful if there were a pre-installed local database of common use cases for each utility, and the user invoking the utility could interactively decide whether to allow specific exceptions, with a big fat warning.

Then, it doesn't matter whether someone exploits your tool, they're only ever allowed to utilize the tool for its intended use cases.

Absolutely agree! It's even more true for closed source software like Skype - to be able to prevent it from accessing to data it doesn't have to.

I know there are many alternatives to Skype, but there are people that have to use it from time to time for professional reasons.

I started doing this for Skype on Ubuntu 14.04 - but have to admit that I quickly ran out of steam. Need to pick up where I ended.

Isn't it impossible to secure Skype because of it's use of X11? I've found it to be impossible to run Skype in untrusted X11 (so that it doesn't get full control over your X display), and running it in a nested X server is probably too slow for video. (And running it in a VM didn't work either for me because of audio and video performance. I really decided I couldn't use Skype except when running it on a real machine dedicated to running Skype.)

You can run Skype inside a docker container: https://wiki.archlinux.org/index.php/skype#Docker

"It is possible to use Skype in a safe Docker container. The program is then run through an SSH tunnel with X11 forwarding and sound is heard through PulseAudio's Network Server."

Well...

1. how is video speed through the ssh tunnel, then? Unsolved, I guess.

2. as I said, Skype won't do untrusted X11 (at least the version I tried didn't). This means that you need to tunnel it with trusted X11 access. Which means, no security (it will log your passwords and open and use X terminals if it wants to). Which makes the whole exercise moot.

Other suggestions on this page are suffering from the same flaw. It seems all the writers of that page have never heard that X11 doesn't provide security. Also, they advise to use xhost. In the end you're worse off when following the recipes on this page than you were before.

If you have a smartphone you could use that as your Skype-machine. I have a cheap Chinese Android phone bought 1 year ago and it can take video calls easily. The point being that in most cases you don't have much choice giving up security on your phone anyway so you may as well put all the spyware in one place.

I agree that it is impossible to completely secure Skype because of X11. And I need as well for some calls the screen sharing feature. So for me this is a wanted feature.

But I would appreciate if I knew that Skype is _not_ able to access my confidential files through the file system. As a bonus it would be great if I could as well forbid Skype to access the local network and just allow it to talk through the default gateway.

I then would start Skype on the laptop only when I have to speak with people. During these teleconferences I anyway have to clean my screen. After the call I can stop the skype process but keep being reachable through skype on phone.

Would this scenario be possible or is there still a security risk for my data?

It is my understanding that once an app has access to full X11, it can do everything you can do with your keyboard and mouse[1]. Like open terminals, cat files, it won't even have to parse the result from the screen if xsel or a text editor is installed since it will be able to copy their content from the clipboard. Or it could run wget or netcat or similar to download a binary that will connect to a server to upload your files.

I suppose that normally you're able to see these activities. But the app could observe periods of inactivity so as to wait until it thinks you're away, then quickly open a terminal, enter the command to wget then start the binary in the background and close the terminal again; that might be like 1/10 second of flickering. Or it might even be possible for it to act similar to a window manager and open the window where it wants, like off-screen or behind other windows, so you wouldn't see anything.

Since it directs the window manager or panel program to open the terminal instead of starting the binary directly, any SELinux properties that say that commands exec'ed by Skype don't have the permission to do stuff will not trigger. You can't stop the panel from opening programs of course unless you're fine with preventing yourself from doing the same. (I don't think SELinux is able to track which X connection leads a panel app to start a binary; that would require it to be able to track code execution and understanding the logic of the program, which seems too complex to be feasible. Cooperation between panel and SELinux might solve this. But then this seems more like a cat&mouse game, will you not have missed other ways in which a program can be started? What about terminals that you opened, they would have to cooperate as well. In the end what you need is a replacement for X11.)

[1] it is possible to inject keyboard and mouse events into the X11 event delivery system; although it might be possible for programs to differentiate between those and real keyboard/mouse events (I know that the events are tagged as articial or some such, but can the programs ignore them without ill effects, and are they doing it?) Here my knowledge is getting spotty, so perhaps it is still possible to get a (somewhat?) more secure situation than what I've depicted above. You'll have to ask someone who knows better. In any case it seems to me that entities that are willing and able to use Skype to break into people's computers will also have way more funding than you to find any obscure ways in which X11 can be used to break out. X11 (at least its normal, trusted mode of operation (and as I said, Skype won't run in untrusted mode)) isn't designed to provide security.

Thanks for your long post. That is really scary! I will still try to get Skype constrained with apparmor. At least I will know that it will not siphon the data through the file interface.

I am wondering if Wayland will be more secure by design. I hope, since it is highly awaited as something that will save us from X11.

Denying applications the ability to send faked input events is one of the design goals of Wayland. This makes some things more difficult, e.g. virtual keyboards.

http://lwn.net/Articles/589147/

Yet when apple makes a sandbox for apps -- which is basically this design, yet usable by people who don't understand software construction or libs -- people shriek. A sandbox is a security boon for the vast majority of people. And I think this is the only way to get reasonable security; we've been banging on this "reduce bugs" plan for at least a decade with much less progress than one would hope to show for it.

It's ironic that even Android now has SELinux enforced by default, yet most Linux distros do not, even though they had support for it since a decade ago.

The reason for this is that SELinux is a nightmare to configure, and lots of peoples expectations break when dealing with it and they usually don't know how to fix things without just disabling SELinux entirely. For Android peoples expectation has from the beginning been set to expect to run into security restrictions.

That's much, much less true than it used to be. These days there's great tools for managing and modifying selinux policy, and much better reporting of what was denied, when and why, and how to fix it.

The "Selinux is too hard for mortals" thing is a relic from the early days of its inclusion into linux, and turning around this attitude is important.

Depends how well integrated it is into the system. I tried to add any MAC to my Arch and discovered that: 1. doing everything from scratch for Tomoyo, including plugging it into grub config and creating your own policies is easier than even getting proper tools for selinux 2. Tomoyo behaves like Apparmor (policies on names not inodes), but can do more (ioctls, devices, more granular network controls) 3. Nobody uses Tomoyo and I really don't get why...

Yeah, it's going to be an uphill struggle on any distro that it isn't already well integrated into - there's a lot of effort that goes into making SELinux in fedora/RHEL/etc JustWork(tm). Duplicating this on a distro without tight SELinux integration is going to be hard - but I tend to feel that if you use arch, linux from scratch or other similar distro, it's not really fair to blame SELinux ;)

I disagree. The tools are awful and terribly slow to execute at best. Then you occasionally get shafted with a relabel.

Can you be more specific? There's lots of different tools available - there might be some better options available than what you're using. And while tools that change things (e.g. setting booleans, changing context rules, etc) are unlikely to be instant in the near future, as the policy needs to be re-compiled, this has been improved, particularly for booleans. You can also batch updates together, which is a much nicer experience if you're trying to set a bunch of things at once. e.g. semanage -i <( echo -e "boolean -m --on httpd_use_nfs\n boolean -m --on httpd_use_sasl") That said, "this admin command I rarely use takes 30s to run" (30s seems to be about the average on RHEL 6/7) is to me an odd reason to try to avoid an important security feature.

I don't recall the last time I had to do a full relabel on a production system. Not saying it hasn't happened, but I can't recall an instance.

Overall, I spend less time managing SELinux (and that includes the custom policies I maintain) than I do managing IPTables. It's really not the nightmare it's made out to be.

It's not that it's too hard for mortals, but that it provides a level of resistance people are not used to, and don't know how to deal with, and where the easiest solution is to turn it off.

Whereas on Android, people expect the barrier, and developers don't expect to be able to disable it.

This is what people were saying not too long ago on Windows when we'd complain that the apps didn't work if the user running them wasn't a local admin. Now you'd be hard pressed to find non-legacy software that doesn't work as a non-admin. In the commercial world, pressure can be brought down from on high - executives and IT purchasers discriminating against shitty software. What about FOSS? If the community has a 'meh' attitude with SELinux then things won't be easily SELinux compatible because devs don't give a shit. The same way most devs don't give a shit about most security related topics.

I'm really worried that Linux has become a liability. The lax security practices of the culture its part of are obvious. What now? Do we migrate to OpenBSD? I've been considering this at work. It just seems that the culture surrounding OpenBSD just takes security more seriously.

The idea that we can just put a application on the internet sounds dangerous to me. If its isn't hardened by something like apparmor/selinux and also behind some kind of application-level firewall (or at least snort), then we're just asking for trouble. Something has to change. The status quo is now failing us. How many high-priority patches have there been in the FOSS world this year?

Sadly, I worry more about my linux machines than my windows machines.

What "most Linux distros" are you talking about?

Ubuntu has Mandatory Access Control in the form of AppArmor (https://wiki.ubuntu.com/AppArmor). It's switched on with a set of policies on the desktop (do sudo apparmor_status to see) and on the server.

On the mobile side a lot of work has been done to confine individual applications in a manner similar to Android. That's future work that could go into mainstream Linux eventually.

On the traditional server side both RedHat and SUSE have MAC on by default - for them SELinux I believe.

If only we could abandon c and c++. That would make most security bugs go away. Source: Mozilla

It would make most security bugs caused by unsafe by default memory management which do account for a high percentage of security bugs, but logic bugs also cause security issues. See for instance SQL Injection attacks.

Yes, but I can't help but imagine how an OS written in Rust would look. Probably a lot better than what we have today. A combination of Rust and D would probably be capable of doing everything C and C++ can, and much better.

Let the language wars commence!

In reality, there is nothing wrong with C++, particularly not modern C++ (since c++11) as the approaches laid out in Stroustrup's book discourage writing C++ in the old-fashioned "let's throw pointers around!" approach.

As with ANY language, if you write it badly, bad things will happen. The language choice doesn't mean bug-free code.

> In reality, there is nothing wrong with C++, particularly not modern C++ (since c++11) as the approaches laid out in Stroustrup's book discourage writing C++ in the old-fashioned "let's throw pointers around!" approach.

So, in essence this would mean to many that Rusts safety focus happens too late for it to be a big enough benefit for having to give up the investment in modern C++? As in, memory safety is a solved problem with modern C++?

Yes, modern C++ is far safer than the old style or passing pointers all over the place and wondering who was deleting them (not that I ever did that - you could pass const pointers to stop others deleting them anyway; it was only a problem if you didn't obey const-correctness and make certain classes "container" classes).

The addition of move semantics and using references everywhere makes pointers unnecessary for the most part. You can use STL containers for putting your items into so shouldn't see raw "new" or "delete" operations in your own code very much; this is particularly true where you define your own move operators and move constructors.

It's a difficult habit to break though!

See Stroustrup's "The C++ Programming Language Fourth Edition" (the blue book) section 3.3.3 Resource Management and 3.2.1.2 "A Container", where in this early part of the book Stroustrup explicitly directs to 'avoid "naked" new and delete operations" and to "use resource handles and RAII to manage resources".

See std::move to force moving where it isn't clear that you're moving things.

Further reading: http://en.cppreference.com/w/cpp/language/move_operator http://stroustrup.com/C++11FAQ.html#default2

The sad reality that I came to realize from this year's CppCon is that most C++ developers out there will just keep on writing pre-C++98 code, due to multiple reasons like style guides, company policy, old code bases and so on.

Only greefield projects can benefit from modern C++ and there are very few out there.

After reading the updated version of Effective C++, I doubt the average C++ developer will be able to deal with a mixed codebase of pre-C++98, C++98, C++03, C++11 and C++14.

This is very true. I am writing new software for my dayjob but I am stuck with VC2010 on Windows. Despite having Xcode under Mac OS, I have to write old-fashioned C++ as VC2010 doesn't support anything new!

But it helps to learn the new stuff and apply it within my own projects as best I can.

> , but logic bugs also cause security issues. See for instance SQL Injection attacks.

Though it seems that some languages, or at least how they are used, are more disciplined when it comes to treating things like SQL queries/commands; that they don't treat them as plain text, and instead assign some kind of structure/typing to the query command. Or don't they? I don't really know how SQL injections are handled in such languages, but I do know that some like to be more principled when it comes to SQL queries/commands in the source code text; like using macros to ensure that an SQL query doesn't have a typo in it. Maybe that kind of practice extends to validating user input.

Strings are a big security hole that doesn't get nearly enough attention.

Conceptually there are a ton of different string types. File names, path names, SQL query templates, SQL query strings, URLs, URL query parameters, command line arguments, full command lines, human-readable text.... Yet just about everything gloms them together into one "string" type. Even APIs that allow for structured construction of SQL queries tend to rely on the programmer not to put arbitrary data in the template bits. These really should all be completely separate types requiring conversion.

See for instance SQL Injection attacks.

Or more recently and widely publicised, ShellShock.

The problem described in this post is beyond just a buffer overrun. It's about pulling in huge numbers of libraries for a few conveniences.

Rust can't save you from that; pulling in libraries makes it way too easy to increase the surface area of your code by several orders of magnitude. Even assuming rust offers an order of magnitude better security than C/C++, it still can't keep up. Sure, it mitigates things a little, but only until the next whiz-bang library gets linked in (even if it's written in rust, it will have some flaws).

In other words, the security of a program is based on the absolute number of bugs in it; but a programming language can't do much more than reduce the ratio of bugs to program size.

The OS is in a much better position to address the problem.

Even including a standard C/C++ library can contribute unknown bugs. I have a prototype system on which the software crashed about once every 3 days until I updated the C library.

"people shriek"

Can you expand on that?

there's a search function on hn; most combinations of osx, sandbox, app, apple will yield results

just one example: https://news.ycombinator.com/item?id=3191021

People shriek because Apple isn't giving the device owner any option to get around the security if they want to.

Apple aren't using that model just for security, but also so they can tightly control the platform and restrict what the device owner can do on it.

on my mac:

   apple -> system preferences
   security + privacy
   General tab
   Under "allow apps downloaded from:"
   * Anywhere

As for ios, if you don't believe that users would click "yes" to whatever dialogue was required to make an app run, you simply don't interact with users. Allowing users to opt-out defeats the purpose. For example, my so's mother regularly gets her gmail hacked because she will respond to any google-skinned input box asking for her password. The only way to secure the majority of users is to not allow them through their actions to un-secure themselves.

Why is it ok on mac? Because many computer users are still dependent on non-appstore distributed software. Particularly developers. Nobody has evolved that dependency on ios, so it's not necessary.

> As for ios, if you don't believe that users would click "yes" to whatever dialogue was required to make an app run, you simply don't interact with users. Allowing users to opt-out defeats the purpose.

It does not require "Click here to get owned" level of work around. I'm perfectly fine with needing to boot into the equivalent of single user mode and entering some security key. But if I want to break the security model on a device I own I should be able to.

> Why is it ok on mac? Because many computer users are still dependent on non-appstore distributed software. Particularly developers. Nobody has evolved that dependency on ios, so it's not necessary.

That is circular reasoning. The "dependency" doesn't exist on iOS because Apple tries very hard to prevent non-appstore distribution being a viable avenue for app developers.

> People shriek because Apple isn't giving the device owner any option to get around the security if they want to.

You are misinformed. Right click -> Open instead of double click overrides my current signing requirements and executes the app anyway.

Where do I right click on my iPhone?

I was talking about iOS. I've never heard anyone "shriek" about this issue in regards to OSX.

I think that Apple is, on the whole, doing the right thing. But it's unfortunate that these three things (kind of) coincide:

* The Mac App Store's business model, i.e. no upgrade pricing, no trial versions; content-wise, nothing that you wouldn't sell in Disneyland

* Paying $99/yr for a developer account, even for free apps

* App sandboxing

And even then, this still doesn't mean that all apps on the App Store are safe. Because you used to be able to submit unsandboxed apps; as far as I know, they have never been removed? Sigh...

But at least many of the currently un-sandboxed apps are moving to the browser (MS Office & Skype being my biggest worries).

I totally agree.

But here's the thing: if you want a secure platform usable by the majority of people, the best choice (by a lot) is ios, followed by osx. The app store is certainly imperfect, but hopefully that will get tightened up over the next couple years.

Relatives who've been hacked ask for how not to get hacked, and my best answer is the above: use ios, particularly for banking. For a laptop, use osx and buy programs either from well known brands (adobe, microsoft) or buy app-store apps.

You can't opt-out of Apple's sandbox.

Apparently you can opt-out at some level.

I’m running Yosemite 10.10.1; according to Activity Monitor, Dropbox, VimR and Terminal aren’t sandboxed.

Of course, many low-level processes aren’t sandboxed either.

I think this approach would still fail if the program is not behaving as expected by the user.

For instance, I didn't know until reading this article that 'less' on ubuntu went through lesspipe, but the people maintaining the tools know that. If for some legitimate use case lesspipe needed access to the internet, the local database could allow that behavior without any warning, but as a user I would still be dumbfounded that a 'less' command ends up generating network connections.

Reply on news.ycombinator.com