--- Joshua Brindle <[EMAIL PROTECTED]> wrote: > Casey Schaufler wrote: > > --- Joshua Brindle <[EMAIL PROTECTED]> wrote: > > > > > >> Casey Schaufler wrote: > >> > >>> --- Joshua Brindle <[EMAIL PROTECTED]> wrote: > >>> > >>> > >>> > >>>> Casey Schaufler wrote: > >>>> > >>>> > >>>>> --- Joshua Brindle <[EMAIL PROTECTED]> wrote: > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>>> ... On the guard > >>>>>> implementation I'd like to note that assured pipelines are pretty hard > > >>>>>> to get right. Without object class and create granularity (at the very > > >>>>>> least) you might find it very difficult to control backflow. Consider > >>>>>> that 1) many IPC mechanisms in Linux have pretty big back channels, > like > >>>>>> > >>>>>> process B being able to pull X number of bits off a unix stream socket > > >>>>>> and A being able to discover how much he pulled off. Also note > >>>>>> bitmap-style attacks where A can create lots of blocking IPC's and B > can > >>>>>> > >>>>>> go through and unblock the ones that he wants to be an 'on' bit. > >>>>>> > >>>>>> We have a paper on this you should read, > >>>>>> http://selinux-symposium.org/2007/papers/11-SecureIPC.pdf > >>>>>> > >>>>>> The solution in SELinux was to allow only a small, trusted helper app > to > >>>>>> > >>>>>> create the message queue (only 1) to avoid the bitmap attack so the > only > >>>>>> > >>>>>> overt back channel left is a very low bandwidth 'pop per time period' > >>>>>> style attack. We've gone through alot of effort to figure out how to > >>>>>> minimize the back channels in assured pipelines and still offer some > >>>>>> reasonable functionality, you'd probably benefit from the work we've > >>>>>> done on this topic. > >>>>>> > >>>>>> > >>>>>> > >>>>> Since you've done your research on the topic I felt that it would only > >>>>> be fair if I did mine before responding. I took a simplistic approach > >>>>> to the problem and chose INET domain UDP datagrams as my mechanism > >>>>> for IPC and hacked together a suite of programs that implement a > >>>>> guardbox. The implementation is crude at best, and the "guard" lets > >>>>> anything through, but all the components are present. > >>>>> > >>>>> The suite consists of 5 programs: > >>>>> origin-sgp: a deamon that passes files from the origin directory > >>>>> to the guard deamon. > >>>>> guard-sgp: this deamon is passed files and decides if they should > >>>>> be passed along. Those that should are passed to the > >>>>> public deamon > >>>>> public-sgp: receives data from the guard and places it gently into > >>>>> the public repository. > >>>>> launch-sgp: fires up the three deamons above. > >>>>> ui-sgp: the user interface program, it sends publication > requests > >>>>> to the origin deamon. > >>>>> > >>>>> These access rules are used: > >>>>> > >>>>> Origin Public rx - A process at the original label can read the > >>>>> Public repository. Handy for checking to see > >>>>> that the transfer was successful. Not required > >>>>> for the guardbox to work. > >>>>> Origin Guard w - The origin deamon can write to the guard > deamon. > >>>>> Guard Public w - The guard deamon can write to the publicator. > >>>>> > >>>>> Each of the deamons checks that incoming packets: > >>>>> - come from the socket specified in the configuration file > >>>>> - come at the label specified in the configuration file > >>>>> - are part of a properly ordered set that makes a complete file. > >>>>> (well, the data's there, my hack doesn't check it very well) > >>>>> > >>>>> > >>>>> > >>>>> > >>>> I may be confused but it seems like you are encoding part of the policy > >>>> into the application behavior rather than relying completely on smack to > > >>>> implement the policy and prevent unintended information flow. > >>>> > >>>> > >>> The checks that the deamons do on the incoming packets are not > >>> necessary to the policy enforcement. Checking the remote port > >>> and the delivery label are simple actions, so if you know what the > >>> value should be, why not have a peek? I'm sure that there are people > >>> who would insist on the data being encrypted and every packet > >>> checksummed. > >>> > >>> > >> Both of which can also be done outside the application layer ;) > >> > >> I'm still pretty sure that, while you might not be providing really high > >> throughput backchannels you aren't doing an incredible job of minimizing > >> them either. > >> > > > > UDP is a datagram protocol that does not provide feedback regarding > > delivery. Each communication step uses UDP and no other means to send > > information in one direction. > > > > What backchannel are you concerned with? > > > > > > read below. > > >> There are plenty backchannels in most Linux IPC and since > >> you don't provide object class granularity you are letting the > >> applications choose which ones they want (which would be the ones with > >> the biggest backchannels if they were trying to downgrade information). > >> > > > > The whole point of a guardbox is to look at the data being > > transmitted. Breaking the system to object class, or any other > > granularity, is not going to change the content inspection > > process. And the whole point of a guardbox is to selectively > > downgrade data based on the makeup of that data. > > > > So I guess I'm just confused. > > > > > > Yes, and in the "old days" it was fine to essentially trust the entire > mechanism that looked at the data but more recently _some of us_ have > decided that we don't really want to completely trust that mechanism so > we break it into a bunch of small pieces and use MAC to ensure the > unidirectionality (a so called 'assured pipeline').
Who you calling old? When you say "that mechanism" what are you talking about? At some point an application that is aware of the data content policy has to be invoked, and no amount of decomposition is going to fundamentally change that. > So with SIPC we can have 5 filters and 2 endpoint processes that each > have a very high forward throughput Sounds familiar so far ... > and a very low bandwidth backchannel The guardbox I proposed has no backchannel. The origin daemon can write to the guard, but not read, and the guard can neither write to nor read from the origin. Similarly the guard can write to the publisher, and the publisher cannot read either origin or guard data, nor write anything back. I have considered a distinct backchannel path that uses it's own daemon to which the guard can write and that can write to the origin daemon. That code is simple enough, and has the same sort of issues that the guard does regarding compromise. > and one has to compromise all of them to get information through that > wasn't suppose to get through (and still they have a very low bandwidth > channel they have to use). Right, with I scheme I've outlined the only way to get bad information to the origin is for the publisher to put it where the origin can read it. > With smack this isn't the case, if every process gets compromised they > can just make connections to each other that utilize other IPC > mechanisms that have higher throughput backchannels. Ah. And those IPC mechanisms would be ... > One example is to use pipes, Since unprivileged programs (the origin, guard, and publication daemons in smackguard run without privilege) can't change their Smack labels establishing a pipe between processes with different labels is not possible without privilege. > quoted from the paper I referred to earlier in this thread: > ""The write system call provides another back channel > for non-blocking FIFOs. The write system call is > implemented in such a way that it writes as many > bytes as possible and returns the number of bytes > successfully written. Using this knowledge, it would > be possible for B to manipulate the size of the buffer > by only reading a certain amount of data, thereby > causing a value to be transmitted back to A via the > write call. This channel could transfer large amounts > of data even with SELinux enforcing unidirectionality > on the data pipeline."" It looks to me like SELinux has the weakness, allowing this IPC to be used in this way whereas Smack does not by prohibiting the scenario in the first place. > Since smack doesn't provide object class granularity it can't (at least > as of yet) protect against this kind of attack. How does object class granularity protect against this kind of attack? If you're suggesting that you use it to prevent the application from using pipes, I have a coarser grained solution, which is to not let the application use any mechanism that allows the prohibited communication, and that would include pipes. Pipes are a really poor example because of the way that they are created and shared only by processes related by fork(). Smack has no trouble with pipes because the endpoints will always have the same Smack value in the absence of privilege. > > > > >> I'll grant that just about every solution created doesn't really take > >> this into account but the SIPC effort was to make a library that could > >> be used by applications and a set of policies that made a very minimal > >> backchannel, high forward throughput and still have decent reliability. > >> We are, in fact, using SIPC on some solutions in development and it > >> seems pretty promising. > >> > > > > Cool. When will we see the Smack port? > > > There is no SELinux specific code in it, anyone can use it anywhere (but > it is only useful where there is MAC to enforce its model) Also cool. Can you point me at the current version, and I'll see about putting together a Smack based package. > One part of the model, however, is to have a helper app that creates the > message queues. This was implemented so that A couldn't create arbitrary > amounts of queues and use the blocking backchannel to increase the > backchannel bandwidth. Since smack doesn't implement that level of > permission granularity you'd have problems implementing the necessary > controls. That sounds like a challenge to me. Good fun. Casey Schaufler [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-security-module" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
