Not logged in
Log in now
Create an account
Subscribe to LWN
LWN.net Weekly Edition for December 5, 2013
Deadline scheduling: coming soon?
LWN.net Weekly Edition for November 27, 2013
ACPI for ARM?
LWN.net Weekly Edition for November 21, 2013
Security in the 20-teens
Posted Feb 2, 2010 0:59 UTC (Tue) by jamesmrh (guest, #31622)
In terms of all of the objects on the system, they have security labels, and the policy will determine if information can flow from one place to another via a certain application running as a certain user.
e.g. you may not be able to open a 'secret' file for read and an 'unclassified' file for write.
You also then to label information as it enters the system.
In the case of, say, someone typing 'secret' information from memory into a text editor which has an 'unclassified' file open for write, it's impossible to prevent. You can try and detect that it's happened after the fact (e.g. file scanning), and perhaps add some deterrence via audit.
For the general case, what we'd likely to encounter in this area is inadvertent disclosure, e.g. phishing attacks. Window labeling (XACE) and trusted path may be useful here.
Posted Feb 2, 2010 1:30 UTC (Tue) by dlang (✭ supporter ✭, #313)
in a network firewall, this would be an application proxy that would check that what you send over port 80 is really valid http (and a really good one would check that it is one of the requests that it has been configured to allow)
Posted Feb 4, 2010 10:12 UTC (Thu) by dgm (subscriber, #49227)
Posted Feb 4, 2010 20:39 UTC (Thu) by dlang (✭ supporter ✭, #313)
This is an example of capability that you could have to filter communication between apps on different machines that you do not get with SELinux securing things on one machine.
as for what this would be useful for.
if you have apps that expect things to be text files and throw arbitrary binary data at them you may find a flaw in them and be able to do things as the owner of that process. If you make sure that such bad data can not get to the app you eliminate an entire class of exploits.
Posted Feb 2, 2010 2:30 UTC (Tue) by smoogen (subscriber, #97)
If that is the level of security you are wanting, then you are going to basically need a large budget for every computer. I remember a security policy back in 1995 that had that in its rules for every computer (Mac, PC, Unix,etc) system.. the site would have needed about 8x more people just to make sure the computers were just being used appropriately. And then it would probably only be 99% effective.
Posted Feb 2, 2010 2:47 UTC (Tue) by dlang (✭ supporter ✭, #313)
you do not get the same security by putting everything on one box and waving the SELinux magic wand.
Posted Feb 3, 2010 13:37 UTC (Wed) by foom (subscriber, #14868)
Posted Feb 3, 2010 16:41 UTC (Wed) by dlang (✭ supporter ✭, #313)
However, for all relatively sane protocols, there is checking that can be done that doesn't require as much code (and therefor doesn't have the risk) of the application code that will be processing the request. Properly done the code for the firewall is relatively static and can be well tested. It doesn't need to change every time you add a new function to the application (or change it's behavior), it only needs to be able to be configured to do different checking.
Usually this can be things like (in order of increased complexity)
checking that the message is well formed by the definition of the protocol
checking that the message follows the protocol syntax
checking that specific fields in the message are in a whitelist
Yes Wireshark has a horrible track record in security, but this sort of checking is happening in many firewalls (under names like 'deep packet inspection') for some protocols. There are also seperate 'Application Firewall' products you can get for some protocols. The better IDS/IPS systems do this sort of thing (as opposed to mearly blacklisting known exploits)
Copyright © 2013, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds