Date: Sun, 31 Dec 1995 19:19:11 +1100 From: Bruce Evans <bde@zeta.org.au> To: bde@zeta.org.au, dawes@rf900.physics.usyd.edu.au Cc: hackers@freebsd.org Subject: Re: /dev/io Message-ID: <199512310819.TAA23798@godzilla.zeta.org.au>
next in thread | raw e-mail | index | archive | help
>I think the key point is in how the X server securely feeds back the >list of ports and fb addresses. It would have to be done before entering >multiuser mode -- either built in to the kernel (or handled with >/kernel -c), or by running the X server with a special flag during boot. This reminded me of lkms - you could have the addresses and possibly some kernel X support in X_mod.o - but I think lkms shouldn't be used if the kernel is going to be used at a high security level - they would increase the number of weak points. >If this can be done OK, then I don't think there would be problems with >the same ports being used for both security holes and normal operations >providing the /dev/fb device is single-open (to prevent spying on the >fb contents). Making it single-open prevents the running of multiple >servers, or use of the new DGA extension, but I think that's inevitable >at a high security level. The mapped ports can be determined by accessing them and seeing if a signal is generated (unless the kernel traps these accesses specially). Anyway, port like 3D4/3D5 are likely ;-) to be mapped and they only need one insecure index register in them to cause problems. I think these problems are best handled by not allowing the X server to be restarted (is that what you meant by "prevents running of multiple servers"). Start the X server and let it grab I/O permissions and memory maps the same as now before entering secure mode, and don't allow these operations at all in secure mode. This reduces that problem to the usual one of protecting the server's text and data after it has started. Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199512310819.TAA23798>