why is there not a lisp pc?
in [Lisp]
|
From: Helmut Eller on 20 Jan 2010 06:38 * Frode V. Fjeld [2010-01-20 10:13+0100] writes: > Helmut Eller <eller.helmut(a)gmail.com> writes: > >> Tell me your implementation and I'll show how to modify v1. > > Tell me your flavor of unix and I'll show you how to modify another > process. Here's an example form the machine I'm sitting at now: > > frode(a)shevek:~$ sleep 1000 & > [1] 21184 > frode(a)shevek:~$ ll /proc/21184/mem > -rw------- 1 frode frode 0 2010-01-20 09:47 /proc/21184/mem > > My point is, in all security problems you have to be explicit about what > the threat you're protecting against is. But Unix at least makes a try, by forcing all programs to use syscalls and can refuse to execute some. That was simply not possible on Lisp Machines; everybody could call and modify every function. > Typical linux desktops today have two security domains: "root" and some > user. Root privileges are if I'm not mistaken required only to do > permanent damage to the system as such (i.e. ruin the file-system other > than /home). Note that in at least one sense this is the least > protection-worthy part of the system because you can always download a > new OS CD and reinstall it. Still, you don't want to allow the bad guys to install key-loggers by modifying libc and the like. > (Of course I know there are other issues > involved, but I'm making a one-sided argument here..) Most MS-windows > desktops don't even bother with this protection, and provide the user > with administrator privileges. From a security point of view, it would be better to minimize privileges. Windows at least has some support for that while Lisp Machines has nothing to offer in this regard. > If you have user privileges you can still read and write *everything* > you (qua user) have on disk and in memory, so privacy is out, and safety > is out. So you are saying Unix's security model is bad. What then is the Lisp Machine model? Very bad? > I'm not saying there aren't advantages to the inter-process safety > that e.g. linux provides, but it's not absolute safety, and these > things do crash, and I suspect there is a heavy, heavy cost in terms > of usability (for sure) and performance (perhaps) incurred by this > safety model. All true, but I still think that isolation is very desirable feature and the cost seems quite bearable in the Unix case. Helmut
From: Pascal J. Bourguignon on 20 Jan 2010 07:39 Helmut Eller <eller.helmut(a)gmail.com> writes: > * Pascal J. Bourguignon [2010-01-19 21:24+0100] writes: > >> So you can happily use an OS written in lisp, without a hardware MMU. >> >> (let ((v1 (vector 1 2 3))) >> (defun f (x) >> (if (<= 0 x 2) (aref v1 x)))) >> >> (defun g (v i) >> (setf (aref v i) 0)) >> >> There is no way to call g so that it modify v1: there is isolation in lisp! > > Tell me your implementation and I'll show how to modify v1. Since all > current cl implementations use in-process debugging, it pretty easy to use > the debugging facilities to extract v1 from the closure stored in F's > function slot. E.g. for CLISP, which seems your favorite > implementation, you could do: > > (compile 'f) > (setq vv (aref (nth 2 (sys::closure-consts #'f)) 1)) > (g vv 1) > (f 1) => 0 Yes, but look at what you had to do here! You had to use a function from SYS. It is easy enough to forbid such a access, thus rendering the system safe. -- __Pascal Bourguignon__ http://www.informatimago.com/
From: Pascal J. Bourguignon on 20 Jan 2010 07:44 Scott Burson <fset.slb(a)gmail.com> writes: > On Jan 19, 12:24 pm, p...(a)informatimago.com (Pascal J. Bourguignon) > wrote: >> >> There is no way to call g so that it modify v1: there is isolation in lisp! > > But not on the LispM, which had subprimitives (with names like SI:%P- > CONTENTS-OFFSET if memory serves) to read and write arbitrary > locations within any object, and which were not bounds-checked either. Again, you had to use the specific SI package, which can be prevented easily enough. -- __Pascal Bourguignon__ http://www.informatimago.com/
From: Frode V. Fjeld on 20 Jan 2010 09:50 Helmut Eller <eller.helmut(a)gmail.com> writes: > * Frode V. Fjeld [2010-01-20 10:13+0100] writes: >> My point is, in all security problems you have to be explicit about >> what the threat you're protecting against is. >> Helmut Eller <eller.helmut(a)gmail.com> writes: > But Unix at least makes a try, by forcing all programs to use syscalls > and can refuse to execute some. > > That was simply not possible on Lisp Machines; everybody could call > and modify every function. So, again, what exaxctly is the thread model here? You can argue that some minimally modified lisp system also "makes a try" by some package access scheme or whatever. What do you mean "can refuse to execute some"? In the example I showed you, there's nothing preventing me from bitbanging that process however I want, and the only reasonable interpretation of "can refuse" I can see is where you apply some extra-paranoid kernel patch to disallow this. > Still, you don't want to allow the bad guys to install key-loggers by > modifying libc and the like. What is the essential difference between this and all the things that can be done with "mere" user access? > From a security point of view, it would be better to minimize > privileges. Windows at least has some support for that while Lisp > Machines has nothing to offer in this regard. It is true that lisp machines have very little to offer anyone (in concrete terms) today. We (or I) are trying here to establish precisely what this support that windows/unix provides is. > So you are saying Unix's security model is bad. What then is the Lisp > Machine model? Very bad? I'm not saying that unix's model is necessarily bad, I'm saying that the difference between that and that of the lisp machines is perhaps not as big as one perhaps initially things. In particular in the context of personal desktop systems. > All true, but I still think that isolation is very desirable feature > and the cost seems quite bearable in the Unix case. I think the cost in terms of usability is possibly quite unbearable. So much software is so brittle and user-unfriendly it's downright painful. In terms of performance the picture is more difficult to see, I think. -- Frode V. Fjeld
From: Helmut Eller on 20 Jan 2010 12:48
* Frode V. Fjeld [2010-01-20 15:50+0100] writes: > So, again, what exaxctly is the thread model here? You can argue that > some minimally modified lisp system also "makes a try" by some package > access scheme or whatever. What do you mean "can refuse to execute some"? The Unix kernel can return EACCES "permission denied" instead of executing the request. > In the example I showed you, there's nothing preventing me from > bitbanging that process however I want, and the only reasonable > interpretation of "can refuse" I can see is where you apply some > extra-paranoid kernel patch to disallow this. If your process is executed as a different user than mine then you aren't allowed to overwrite my /proc entries. You can also not overwrite kernel memory and in particular not the parts which implement access restrictions. >> Still, you don't want to allow the bad guys to install key-loggers by >> modifying libc and the like. > > What is the essential difference between this and all the things that > can be done with "mere" user access? Users can execute (access) stuff in libc but can not overwrite it. >> From a security point of view, it would be better to minimize >> privileges. Windows at least has some support for that while Lisp >> Machines has nothing to offer in this regard. > > It is true that lisp machines have very little to offer anyone (in > concrete terms) today. We (or I) are trying here to establish precisely > what this support that windows/unix provides is. > >> So you are saying Unix's security model is bad. What then is the Lisp >> Machine model? Very bad? > > I'm not saying that unix's model is necessarily bad, I'm saying that > the difference between that and that of the lisp machines is perhaps not > as big as one perhaps initially things. In particular in the context of > personal desktop systems. On the Lisp Machine, all memory was shared and readable and writable by all processes, right? On Unix, the bulk of applications doesn't run in kernel space. Seems quite a difference to me. Considering that a whole industry is busy writing anti-virus programs for those PCs, it seems that even a small improvement in the security model could save a lot of money. >> All true, but I still think that isolation is very desirable feature >> and the cost seems quite bearable in the Unix case. > > I think the cost in terms of usability is possibly quite unbearable. So > much software is so brittle and user-unfriendly it's downright > painful. In terms of performance the picture is more difficult to see, I > think. Usability seems harder to measure than performance. I've the impression that those Mac/iPhone using people are quite happy with usability. Helmut |