| |||||||||||||
Security in the 20-teensSecurity in the 20-teensPosted Feb 1, 2010 20:14 UTC (Mon) by dlang (✭ supporter ✭, #313)In reply to: Security in the 20-teens by raven667 Parent article: Security in the 20-teens
if people are not willing to understand their data flow between machines well enough to implement real security with firewalls, what makes you think that they will analyze the data flow between processes on the same machine well enough to implement real security with something like SELinux?
(Log in to post comments)
Security in the 20-teens Posted Feb 1, 2010 20:46 UTC (Mon) by epa (subscriber, #39769) [Link]
I think the idea is that it doesn't depend on 'people' to sit down with the SELinux user guide and a large pot of tea to write the correct policy for their system; rather, the default settings will be somewhat more restrictive and more secure than we have now (where the Flash plugin, for example, can read any file in your home directory). This would close off some, though not all, exploits.
Security in the 20-teens Posted Feb 1, 2010 21:34 UTC (Mon) by dlang (✭ supporter ✭, #313) [Link]
every time you try to create such 'obvious' rules you will break something for someone. And unless the rules are easy enough for that person (or their sysadmin) to understand and modify, all that will happen is that they will learn that the way to make their system work is to disable SELinux, and they will.
This is what is routinely happening with SELinux today, even for professional sysadmins and security people.
getting this stuff right is hard, significantly harder than isolating systems from each other.
it gets even worse, because what you want isn't the binary 'communication via this port/access to this file is allowed or blocked', what you really want is 'you are allowed to do these types of things'. On the firewall side the retreat away from proxy firewalls to packet filters is a wonderful win for the manufacturers of packet filters, but a huge loss for everyone else. things are a little better on the SELinux side (they separate read/write/execute) but there's no control over what they read/write to a file, and you don't know what the impact is of a write unless you understand how every other program that reads the file interprets it.
Security in the 20-teens Posted Feb 1, 2010 21:54 UTC (Mon) by jamesmrh (guest, #31622) [Link]
There is control over what's written in SELinux, and you can determine who can read a file -- these are fundamental design characteristics of the security model. In the default case with Fedora, we're focused mainly on containment of network facing apps, so most people don't see or use this, although information flow control is a big part of govt deployments (see e.g. the CLIP tool for managing this).
Security in the 20-teens Posted Feb 1, 2010 23:03 UTC (Mon) by dlang (✭ supporter ✭, #313) [Link]
SELinux allows you to control if an application can write to a file, but if you are allowed to write to a file, it doesn't give you any way of controlling _what_ you write.
Security in the 20-teens Posted Feb 2, 2010 0:59 UTC (Tue) by jamesmrh (guest, #31622) [Link]
Well, it depends.
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.
Security in the 20-teens Posted Feb 2, 2010 1:30 UTC (Tue) by dlang (✭ supporter ✭, #313) [Link]
this is not was I was saying is missing, what I am saying is missing are controls that would prevent you from inserting 8 bit data into a file of type 'ascii text'
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)
Security in the 20-teens Posted Feb 4, 2010 10:12 UTC (Thu) by dgm (subscriber, #49227) [Link]
Exactly what purpose would this be useful for?
Security in the 20-teens Posted Feb 4, 2010 20:39 UTC (Thu) by dlang (✭ supporter ✭, #313) [Link]
way back up the thread the statement was made that using SELinux for many processes on one machine was as secure as having the processes on separate machines separated by firewalls.
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.
Security in the 20-teens Posted Feb 2, 2010 2:30 UTC (Tue) by smoogen (subscriber, #97) [Link]
No it can't.. but then again.. that is pretty much impossible to do in any OS that isn't written from the ground up to be super secure AND is usually with caveats like: No network, have multi users watch people using input/output devices, make sure every written to file is checked multiple times through multiple people and programs, etc.
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.
Security in the 20-teens Posted Feb 2, 2010 2:47 UTC (Tue) by dlang (✭ supporter ✭, #313) [Link]
but you can get that sort of security between machines. It's not cheap (it requires that you buy real application firewalls, not just cisco, checkpoint, linux, or *bsd stateful packet filters) and it requires that you take care about what your software is doing, but it is possible.
you do not get the same security by putting everything on one box and waving the SELinux magic wand.
Security in the 20-teens Posted Feb 3, 2010 13:37 UTC (Wed) by foom (subscriber, #14868) [Link]
But, once the firewall is parsing application traffic, who's to say it doesn't have the security holes
just like the application does? (Wireshark certainly has its fair share of remote exploits, for instance).
Security in the 20-teens Posted Feb 3, 2010 16:41 UTC (Wed) by dlang (✭ supporter ✭, #313) [Link]
yes, any checking the firewall does opens the firewall up to the possibility of errors (this includes the checking done in stateful packet filters)
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)
Security in the 20-teens - Default security policies Posted Feb 2, 2010 14:18 UTC (Tue) by eparis123 (guest, #59739) [Link] Every time you try to create such 'obvious' rules you will break something for someone. I completely agree. From around a month, I was very late on a college project that involved loading binary files to a MySQL database. Using ubuntu, the queries always filled NULL in the binary files columns, without any visible error messages. After around 40 minutes of Googling, I found that the reason was an AppArmor policy enabled by default in Ubuntu. I even found it on the very last comment of a MySQL bugzilla entry. Needless to say, I was very frustrated I consumed all that time on this trivial matter, while having very limited time till the deadline. I guess this is a pet example for users frustration with security; Casey Schaufler (author of SMACK) had a great quote about this in one of the previous weekly editions kernel quotes page.
Quote candidate Posted Feb 3, 2010 21:09 UTC (Wed) by man_ls (subscriber, #15091) [Link] Maybe this one? I don't see how it relates to AppArmor though.
Quote candidate Posted Feb 4, 2010 19:12 UTC (Thu) by eparis123 (guest, #59739) [Link] Yes, this was the one I meant. The relation I find is that an application developer (me, innocently working on a MYSQL program) got bitten heavily in the worst of times. Maybe I did not understand the quote context very well too.
Accurate quote Posted Feb 4, 2010 21:11 UTC (Thu) by man_ls (subscriber, #15091) [Link] He said: "Application developers have historically been intolerant of systems that change their security policy on the fly." It was me who was missing some context; in fact it was some silly grammar mistake on my part. I thought "their" referred to "systems", not to "application developers", and didn't see how AppArmor changes its own security policy on the fly. It doesn't; it changes application developer's security policy. And yes, it is annoying when that happens.
|
|||||||||||||