On Wed, Feb 12, 2003 at 06:52:41PM -0500, bdonlan wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On Wednesday 12 February 2003 06:38 pm, Mark J Roberts wrote: > > Jay Oliveri: > > > I don't know what to really think, since conveniently most of > > > their evidence is under NDA. > > > > Devising access control and permissions schemes to limit the > > capabilities of code processing malicious data is a tricky business. > > The question that needs to be constantly asked is, "Exactly what > > capabilities does this program currently need?" > > > > For instance, to play a movie from a file, mplayer needs to do three > > things: > > > > (1) read the file > > (2) write to the screen > > (3) write to the sound card > (4) load plugins > (5) Access the RTC > (6) Get access to raw video RAM... > Shall I go on? :) It should be possible to map the DGA buffer in and then give up that particular capability though, surely? Anyway on a full MAC system like SELinux, or at least some sort of capabilities and chroot jails system, it should be possible to greatly reduce possible harm. > > > Consider the command: > > > > wget ftp://user:[EMAIL PROTECTED]/file.mp3 > > > > Like mplayer, we can specify that it needs to: > > > > (1) create "file.mp3" and write to it > > (2) establish a tcp connection to server.com > > > > But (2) can be more specific; in fact, security demands that it be. > > What if wget is compromised by some malicious server response, and > > rather than merely downloading "file.mp3", deletes all your files on > > the server instead? > > > > The FTP commands wget may use must be explicitly specified! > > > > Now, what is the most generic and powerful way to accomplish these > > things? > > > > One solution: upload a routine to the OS which may be called later. > > In the case of wget, the network code, configured at initialization > > time to only do what is necessary to download "file.mp3", is > > uploaded to the OS, and its capabilities are extended to include > > connecting to server.com:ftp. wget then freezes its capabilities, > > revoking permanently its ability to upload any further routines or > > acquire any further capabilities, and executes normally, making use > > of the uploaded networking code when necessary. This is one of several reasons why keeping wget separate from mplayer i.e. downloading the whole file in one restricted environment and then playing it in a totally different one is a reasonable precaution. > > Er, uploaded to the OS? What would be the point? Uploading code to the local > system is unnecessary. Anyway, it could prepare a TCP packet looking like > this: > USER user > PASS password > PASV (options) > MODE I > GET /file.mp3 > QUIT
You could surely do something with packet filtering, yeah. The point with all this is that not only does it often require kernel patches, it is one hell of a lot of work and it gets in the way of "features" such as streaming. In future, maybe SELinux will be merged into major distribution's kernels, and packages will distribute various config scripts for their programs with various levels of paranoia doing particular tasks, implemented mainly by SELinux's MAC stuff, but it will still be a lot of work. > > and upload it, then close the sending side of the socket, then just listen for > server responses. > > > Of course, if the uploaded code itself is vulnerable to exploits, > > the elevated capabilities of the uploaded code may be exploited. > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.2.1 (GNU/Linux) > > iD8DBQE+St5Jx533NjVSos4RAo5KAJ909ioorYV0uaPKeEbgLqd1lCrmbgCgsl9q > g7Gims08ObuLMV3O+K5SjkI= > =fj+i > -----END PGP SIGNATURE----- > -- Matthew Toseland [EMAIL PROTECTED][EMAIL PROTECTED] Full time freenet hacker. http://freenetproject.org/ Freenet Distribution Node (temporary) at http://amphibian.dyndns.org:8889/KcW66rKIGAU/ ICTHUS.
msg06757/pgp00000.pgp
Description: PGP signature
