--- Joshua Brindle <[EMAIL PROTECTED]> wrote: > Casey Schaufler wrote: > > --- Joshua Brindle <[EMAIL PROTECTED]> wrote: > > > > > >>> 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. > >>> > >>> > >>> > >> That may be the case with unnamed pipes but what about named ones? > >> > > > > Named pipes require read access to open, even for O_WRONLY, like all > > other file system objects. > > > > > >> Sockets (datagram and stream) have similar backchannels related to > >> blocking state and buffer size. > >> > > > > INET domain UDP provides neither blocking nor buffering feedback > > that I'm aware of. That's why I'm using it. What am I missing? > > > > > > > > Ah yes, I believe that you are correct. We didn't look at non-local IPC > when we wrote that paper due to lack of network labeling at the time. > One question I have though, is how do you guarantee delivery with UDP? > SIPC had 2 goals, to have a high throughput forward channel and to have > good reliability (which necessitated the second very small back > channel). Without the need for good reliability we could have just used > shm and a timer (which I bet you could use and get better performance > than UDP...)
By definition UDP is unreliable, so the application has to take ownership of making sure of the delivery. The obvious approach is to put a serial number in the message header. If a message arrives out of sequence, corrupted, or just not smelling right the receiver will discard all messages associated with that transfer and never send it along. Is this reasonable? I'm having real trouble coming up with a way to get the thing to fail, to ensure that the error detection works right, without doing artificial injection. I'll have to look into the shm+timer scheme sometime, but as I'm really only looking at a sample implementation my throughput concerns are not significant. > <snip> > >>> > >>> > >> Yes, http://oss.tresys.com/projects/sipc/ is the webpage, it looks like > >> we only have an svn repo of it up right now, not packaged sources, that > >> shouldn't be a problem though. Note there may be some API changes coming > >> soon... > >> > > > > Sigh. Another tool to learn. > > > Don't worry, we'll switch to mercurial soon :) Good luck with that. 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
