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

[Robert Goldman]

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, ...)

Possible alternative approach:  make a package for each user by hand.
Do *not* (:use COMMON-LISP).  Let individual symbols in if you feel they
can be trusted.  Make sure you don't admit find-symbol, intern, and
their kin!  Break the reader as you have already considered.

Cheers,
r