[Openmcl-devel] modify lisp reader such that :: is disallowed

[mikel evins]

On Jun 11, 2009, at 12:23 PM, Taoufik Dachraoui wrote:

>
> On Jun 11, 2009, at 6:51 PM, mikel evins wrote:
>
>>
>>
>> On Jun 11, 2009, at 11:14 AM, Taoufik Dachraoui wrote:
>>
>>>
>>> On Jun 11, 2009, at 5:56 PM, Ron Garret wrote:
>>>
>>>>
>>>>
>>>> On Jun 11, 2009, at 8:09 AM, Taoufik Dachraoui wrote:
>>>>
>>>>> Hi
>>>>>
>>>>> Users will not have access to intern, find-package, ...
>>>>>
>>>>> I implemented a loader that exports public symbols and shadow
>>>>> unwanted
>>>>> symbols
>>>>> so that users will not be able to use any private or shadowed
>>>>> symbols.
>>>>>
>>>>> the only problem I am facing today (as far as I can see right now)
>>>>> is to
>>>>> disallow users to access non exported symbols by using the double
>>>>> colons (::)
>>>>>
>>>>
>>>> The "as far as I can see right now" is a very important disclaimer.
>>>> The main problem with security is that there's a very big gap
>>>> between appearing to be secure and actually being secure.  People
>>>> make careers out of bridging that gap, and still very often they  
>>>> get
>>>> it wrong.  Not that I really want to discourage you -- it's good
>>>> that you're being ambitious, but it's important that you understand
>>>> the magnitude of the problem you are attempting to solve.
>>>>
>>>>> I tried to use set-macro-character and set-dispatch-macro- 
>>>>> character
>>>>> but failed, and
>>>>> the reason is that the lisp reader as soon as it finds a macro-
>>>>> character the previously
>>>>> read word will be considered as a token and there is no way to
>>>>> rollback.
>>>>
>>>> Why is that a problem?
>>>>
>>>> Is there a reason you don't just pre-process the string to remove
>>>> all colons before reading it?  Or simply reject any string
>>>> containing colons?
>>>>
>>>> rg
>>>>
>>>>
>>>
>>> I thought about processing the string before passing it to the  
>>> reader
>>> but I
>>> think it is better to leave the lisp reader deal with it (faster);  
>>> but
>>> it seems
>>> that there is no solution at sight right now; probably only by  
>>> modifying
>>> (hacking) the ccl lisp reader.
>>>
>>> Another way is to create a set-macro-character for #\: and throw an
>>> error,
>>> but this will inhibit the use of keywords.
>>>
>>> About making lisp secure:
>>>
>>> Suppose you have access to a limited set of symbols (known as  
>>> secure),
>>> and that the colons are forbidden, then how a user can access  
>>> symbols
>>> in packages that he did not inherit?
>>
>> (funcall (intern "LAUNCH-MISSILES" (find-package "TOP-SECRET- 
>> PACKAGE")))
>>
>> (apply (symbol-function (find-symbol "DESTROY-THE-WORLD") (find- 
>> package "THE-EVIL-PACKAGE")) '())
>>
>> (do-symbols (s (find-if (lambda (p) (member "WORLD-ENDING- 
>> PACKAGE" (package-nicknames p))) (list-all-packages)))
>>  (when (and (char= (elt (symbol-name s) 0) #\D)
>>             (char= (elt (symbol-name s) 0) #\E)
>>             (char= (elt (symbol-name s) 0) #\S)
>>             (char= (elt (symbol-name s) 0) #\T)
>>             (char= (elt (symbol-name s) 0) #\R)
>>             (char= (elt (symbol-name s) 0) #\O)
>>             (char= (elt (symbol-name s) 0) #\Y))
>> 	(funcall (symbol-function s))))
>>
>> (do-all-symbols (s) (when (test-symbol-for-function-that-produces- 
>> hell-on-earth s)
>>                         (let ((my-evil-symbol (gensym))))
>>                            (setf (symbol-function my-evil-symbol)
>>                                  (symbol-function s))
>>                            (pass-evil-symbol-to-function-calling- 
>> macro my-evil-symbol)))
>>
>>
>> ...
>>
>>
>>
> As I said earlier, all symbols that allow users to access and/or  
> modify data of other users will be
> shadowed (eg. intern, in-package, find-symbol, do-symbols, ...)

That's a lot of symbols! The implementation in front of me has about  
9,000 symbols that name functions. I wonder how many of them have  
malicious potential uses? I wonder how many can be combined with some  
number of the other ones to result in a security hole? Phew, that's  
going to be quite a bit of checking!

I'm not saying you should give up; far from it. On the contrary, I'd  
suggest trying to get a research grant for it. If you limit yourself  
to one specific implementation on one specific CPU and OS, that could  
be enough work to keep you busy, interested, and receiving paychecks  
for several years. It could result in some pretty interesting  
publications, too.

--me