Security quotes of the week [LWN.net]

I would say running each service on an individual machine is the most secure. Running Each Service on a separate VM is the second most, especially if you are using SELInux/Svirt for separation of your VM's. Third level is running each Service in a different container, (Again you want SELinux for some separation). Fourth is each Service running on the host, (Wrapped with SELinux). Fifth setenforce 0.

— Daniel J Walsh (Thanks to Peter Robinson.)

Control is moving back to the center, where powerful companies and governments are creating choke points. They are using those choke points to destroy our privacy, limit our freedom of expression, and lock down culture and commerce. Too often, we give them our permission—trading liberty for convenience—but a lot of this is being done without our knowledge, much less permission.

— Dan Gillmor moves away from Apple, Google, and Microsoft products

Some will point out that an MITM [man-in-the-middle] attack on the NSA is not really an 'MITM attack on the NSA' because NSA outsources its web presence to the Akamai CDN (see obligatory XKCD at right). These people may be right, but they also lack poetry in their souls.

— Matthew Green (Thanks to Paul Wise.)

Encryption backdoors will always turn around and bite you in the ass. They are never worth it.

— Matthew Green (in the same blog post)

to post comments

Security quotes of the week

Posted Mar 5, 2015 7:53 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link] (15 responses)

I'd rank them differently:
1) A separate host.
2) A full-system VM (Xen, KVM, VMWare)
3) A container or a regular Unix server.
4) SELinux turned on.

Yes, SELinux has negative worth - it's so difficult to understand and debug that most sysadmins either turn it off at some point or put too much hope on it.

SELinux is kinda like a bike with reinforced titanium run-flat wheels and a frame-mounted machinegun. Sounds impressive and cool, but in reality actually does almost nothing to protect its user. All while requiring to juggle dangerous options all the time.

Security quotes of the week

Posted Mar 5, 2015 8:42 UTC (Thu) by drag (guest, #31333) [Link] (8 responses)

I don't think that SELinux is all that bad. I leave it on all my systems and if I have any issues 9 times out of 10 I just have to switch a booleon option on. I don't argue that at work because I know almost nobody else is the least bit interested in even learning it's basics.

The biggest problem, of course, is that it's trying to do inflict a new security model on a traditional system that never was designed for it. OF course it's going to be a bit of a nightmare. It's really like having a OS that has been around for 70 years that never had any sort of file system permissions before. So then disabling Selinux is like going into a system like that and just running 'chmod -R 777 /' and then shrugging and saying "This really doesn't help much since the most important think is to never code any application that has file handling bugs".

I think that if people develope a effective way to manage and run applications that was developed with security in mind from the get-go then things like SELinux will be massively saner to deal with. Not going to hold my breath, though.

I do find it interesting that Android made the transition to using SELinux by default without much drama. Although that could just be because I haven't been paying all that much attention.

Security quotes of the week

Posted Mar 5, 2015 11:51 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link] (7 responses)

> I don't think that SELinux is all that bad.
It's bad because it violates the main rule of good administrators: "It should be understandable". I contend that no single person knows all the rules and security implications in a Fedora SELinux installation.

> The biggest problem, of course, is that it's trying to do inflict a new security model on a traditional system that never was designed for it. OF course it's going to be a bit of a nightmare.
Yes. The original Unix permissions model is so good exactly because it's so simplistic. It neatly fulfills its design goal - to isolate differnt users on a single machine.

SELinux tries to isolate applications from each other. That's a much more complicated task that in truth requires a complete re-design of the UNIX itself.

> I do find it interesting that Android made the transition to using SELinux by default without much drama. Although that could just be because I haven't been paying all that much attention.
Android has been designed from the very start to isolate applications from each other and it also has a capability-based security model for special permissions.

Thus adding SELinux just strengthened the already existing isolation model. And most of the problems occurred in the same area where SELinux sucks on desktops: removable storage and inter-application sharing.

> I think that if people develope a effective way to manage and run applications that was developed with security in mind from the get-go then things like SELinux will be massively saner to deal with. Not going to hold my breath, though.
It's pretty clear that we're moving towards a more containerized world. And containers need SELinux about just as much as a fish needs an umbrella.

On the desktop we're seeing sandboxes with capability-based security. I think it's the only sane model, personally.

Security quotes of the week

Posted Mar 5, 2015 22:17 UTC (Thu) by sjj (guest, #2020) [Link] (5 responses)

> It's pretty clear that we're moving towards a more containerized world. And containers need SELinux about just as much as a fish needs an umbrella.

Rather, SELinux should be the water in which the containers swim.

Security quotes of the week

Posted Mar 5, 2015 23:12 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link] (4 responses)

Why? In its core SELinux is a system to label everything and pass the labels around.

Containers present a natural border for labels. So what's the point?

Security quotes of the week

Posted Mar 6, 2015 22:41 UTC (Fri) by job (guest, #670) [Link] (3 responses)

You make it sound like quite a good fit. Containers present a natural border for labels. Should be pretty easy and understandable.

And containers really need a good security story, preferrably by yesterday.

Security quotes of the week

Posted Mar 6, 2015 22:50 UTC (Fri) by Cyberax (✭ supporter ✭, #52523) [Link] (2 responses)

The main problem with containers is that they don't actually contain. There are too many ways to escape confinement because of various kernel bugs, including the ones normally inaccessible to regular usermode code.

Labels don't provide much help here. And even sometimes cause havoc if you want to use a MAC inside the container itself and perhaps share resources between several containers.

Security quotes of the week

Posted Mar 7, 2015 12:52 UTC (Sat) by job (guest, #670) [Link] (1 responses)

Sure, that's why some kind of MAC solution is required, and quickly. I have no idea which of the many available fit the problem space best, but if labels map naturally to containers which you suggested, SELinux sounds like a solution as good as anything else.

Security quotes of the week

Posted Mar 7, 2015 22:25 UTC (Sat) by Cyberax (✭ supporter ✭, #52523) [Link]

I don't really understand why MAC is required. It'll inevitably be clunky and hard to use.

I really prefer an architecture of isolated containers with tightly controlled 'escape hatches' to access the shared state or to do important actions. I don't think it can be easily done with labels.

There's a good example in the thread - if you app needs to snap one picture then the classic MAC-based solution would be to give it a "camera_t" label allowing access to the camera. So if some random game needs a one-off access to the camera to scan a QR code from a gift card, I won't have any choice but to give it permanent access.

My preferred solution would be to add a special third-party to mediate privileged requests. So a game can place a request to allow it access to the camera stream and the system can prompt me to grant it.

Security quotes of the week

Posted Mar 12, 2015 0:41 UTC (Thu) by Wol (subscriber, #4433) [Link]

> > The biggest problem, of course, is that it's trying to do inflict a new security model on a traditional system that never was designed for it. OF course it's going to be a bit of a nightmare.

> Yes. The original Unix permissions model is so good exactly because it's so simplistic. It neatly fulfills its design goal - to isolate differnt users on a single machine.

I beg to differ ... having worked with ACLs, they're much better. Okay, a bit more complicated to understand (and I think the Windows version is a nightmare), but if well designed they do a much better job than nix permissions. The problem is the ACLs I've worked with rely on a hierarchical system, so they'll break in a typical nix i-node based filesystem :-(

Cheers,
Wol

Security quotes of the week

Posted Mar 6, 2015 23:47 UTC (Fri) by scientes (guest, #83068) [Link] (5 responses)

SELinux is technically good, but I think the way it is used is backwards: we are building fences around apps instead of building the apps inside fences. (permission-based-security like Android has made wide-spread) The sandbox needs to be the default and apps should be build around it.

Security quotes of the week

Posted Mar 7, 2015 3:22 UTC (Sat) by rahulsundaram (subscriber, #21946) [Link] (4 responses)

I really dislike the Android model. When apps require permissions, there is no way to disallow certain permissions and if an app wants to take a snap for a one time functionality, it shouldn't require me to give it broad permissions to the gallery etc permanently. It's pretty broken.

Security quotes of the week

Posted Mar 7, 2015 8:25 UTC (Sat) by zdzichu (subscriber, #17118) [Link] (1 responses)

Well, Android model let's you selectively block app's permissions. The problem is that stock UI does not expose this functionality. Stuff like http://androidcommunity.com/cyanogenmod-privacy-guard-upd... does.

Security quotes of the week

Posted Mar 7, 2015 18:18 UTC (Sat) by jem (subscriber, #24231) [Link]

App Ops was included in Jelly Bean "by mistake" and removed in KitKat.

http://lwn.net/Articles/577593/

Security quotes of the week

Posted Mar 7, 2015 21:15 UTC (Sat) by cesarb (subscriber, #6266) [Link] (1 responses)

> if an app wants to take a snap for a one time functionality, it shouldn't require me to give it broad permissions to the gallery etc permanently.

That's right! Android was designed to make that possible. You can, within any app, take a picture *without* any extra permissions, by invoking the Camera application via an Intent.

Intent takePictureIntent = new Intent(MediaStore.ACTION_IMAGE_CAPTURE);
startActivityForResult(takePictureIntent, REQUEST_IMAGE_CAPTURE);

This standard Intent was added in Android 1.5. For more details, see:

https://developer.android.com/guide/topics/media/camera.h...
https://developer.android.com/training/camera/photobasics...
https://developer.android.com/reference/android/provider/...

Of course, the Camera application *does* have the broad permissions permanently, but that's because its whole point is to take and save pictures.

I really like the Android model. It's a pity most programmers don't understand its potential.

Security quotes of the week

Posted Mar 7, 2015 21:25 UTC (Sat) by rahulsundaram (subscriber, #21946) [Link]

The problem is not the theory but the practical application of it. The vast majority of mainstream apps request and retain permissions permanently and any attempt to use third party apps to control fine grained permissions leads to weird behavior and outright crashes all too often.