User: Password:
Subscribe / Log in / New account

Security in the 20-teens

Security in the 20-teens

Posted Feb 2, 2010 0:59 UTC (Tue) by jamesmrh (guest, #31622)
In reply to: Security in the 20-teens by dlang
Parent article: Security in the 20-teens

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.

(Log in to post comments)

Security in the 20-teens

Posted Feb 2, 2010 1:30 UTC (Tue) by dlang (subscriber, #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 (subscriber, #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.

Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds