Re: [PATCH 3/7] SLIM main patch

[Serge E. Hallyn]

Quoting Alan Cox (alan@xxxxxxxxxxxxxxxxxxx):
> Ar Iau, 2006-08-24 am 08:32 -0500, ysgrifennodd Serge E. Hallyn:
> > > You also have to deal with existing mmap() mappings and outstanding I/O.
> > 
> > That she does.
> 
> I don't believe so from the patches.
> 
> > > 	SysV shared memory
> > 
> > standard mmap controls should handle this, right?
> 
> No its rather independant of mmap

There are controls on shmat, and shm which has been mmap'ed will be
revoked.

> > > 	mmap
> > 
> > She handles these.
> 
> I must have missed where it handles that.
> 
> > thread #2 is reading data from a pipe which is at a secret level, so how
> > will it exploit that?  It can't write it to a lower integrity file...
> 
> Ok my example isn't quite right - I can create the pipes and do the
> blocking in other patterns to get the result I mean. The problem is that
> I can be blocked in a driver write() method before you raise the
> security level and no change at the VFS level will be early enough to
> stop it.
> 
> Another example would be
> 
> Type ^S > 	thread #1
> 		write(console, padding, internalbuffersize);
> 		write(console, secret_buffer, data) [blocks]
> 
> 	thread #2
> 		sleep to be sure #1 is blocked
> 		open secret file
> 		read(secret, secret_buffer, data);
> 
> Type ^Q
> 
> By the time you raise the security level due to the action of thread #2
> I'm already blocked in tty_do_write() and have passed any vfs checks.

So using the following two patches should solve that problem, by making
sure that the tty pages can't be made writeable again?

Or will the page associated with the tty already have the data, and this
really just needs to be fixed in the tty itself?

-serge