--oC1+HKm2/end4ao3
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Thu, Jul 26, 2007 at 08:02:27AM -0400, der Mouse wrote:
> >> I'm not sure there's more here than a covert channel [...]
> > We should check, but I doubt there is a security issue here.
>=20
> Depends on what you consider a security issue.
>=20
> > All you're going to find is anything extra you scribbled while the
> > page was in cache.
>=20
> No...anything extra *someone* scribbled while the page was in cache.
> Hence my calling it a covert channel: it's something processes can use
> to communicate while appearing to be not communicating - that is, the
> channel is hard to detect (because it never makes it to the file) or
> trace (because it's lost as soon as that page is tossed from cache).

Well, this is always true. The only difference in what we're talking about=
=20
is that the processes involved don't have to be simutaneously running. If=
=20
there were, you could use this channel even w/ older versions of NetBSD.

> Admittedly, this isn't quite the usual use of the term "covert
> channel"; it more usually refers to a method for two entities to
> communicate that aren't supposed to be able to communicate.  But I
> think communicating without appearing to use any channel they have
> (such as a mutually writable file) is close enough that I don't mind
> using the term.
>=20
> This is a security issue in a sufficiently paranoid context.  Is NetBSD
> such a context?  That's the debatable part.  I suspect it is not - we
> have so many other covert channels - but I'd still prefer to see the
> bug fixed.  (Probably not enough to actually do the work myself, so I'm
> not sure attention should be paid to my preferences, of course.)
>=20
> > The one issue we would need to keep track of in "fixing" this issue
> > is that we don't clobber something that's in the process of extending
> > the file.
>=20
> Hmm, that's a good question.
>=20
> Process A:
> 	open 10-byte file
> 	mmap 10 bytes
> Process B:
> 	extend file to 20 bytes
> Process A:
> 	write into the 10-20 byte range of the mapping
>=20
> Should the data process A writes make it into the file?  I'd say it
> shouldn't in an abstract sense, but that could be very hard to arrange,
> especially if you want modifications to the 0-10 range to be shared.

I agree that this'd be hard to arrange. I however think we shouldn't=20
bother. I don't believe that mmap has ever promised to let you map less=20
than a page. Sure, you can ask for less, but you always get a whole page=20
(or pages). So scribbling after what you thought was the end but some=20
other process has made a valid part of the file seems quite reasonable.

Take care,

Bill

--oC1+HKm2/end4ao3
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (NetBSD)

iD8DBQFGqPZMWz+3JHUci9cRAlF7AJ9Z0lTB3G3eMW47EDTsH+O/MfJ22wCfTJRr
N09CYgZKS/3JMvGImke3kP4=
=wHvP
-----END PGP SIGNATURE-----

--oC1+HKm2/end4ao3--