This is the mail archive of the guile@sourceware.cygnus.com mailing list for the Guile project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: Safe Guile?



Roland Orre <orre@nada.kth.se> writes:
> The problem now is that you can't define a module without getting all
> names which are defined in the root module. Correct me if I'm wrong!
> Will this behaviour possibly change (Jost?) ?

Jost Boekemeier <jostobfe@calvados.zrz.TU-Berlin.DE> writes:
> Doesn't `(module (my module) (import ))' or 
> (define-module (my module))
> (module-import )
> do what you want?

Roland Orre <orre@nada.kth.se> answers:
No, at the moment there is no simple way to avoid getting all definitions
from the root guile module.

To make a safe guile you need to know that only those operations that
you have defined to be safe can be exported, which may of course depend
on your level of sequrity.

In such a security module you could also control which new modules
may be possibly loaded if you allow that, and also replace certain
operations, like open-file etc with special restricted versions
for instance.

The only necessary addition which would be needed to the module system
would be a control option telling that you don't want the root module,
like:

(define-module (safe-scheme)
   :use-module (ice-9 slib)
   :use-module (ice-9 debug)
   :use-module (ice-9 threads)
   :use-module (ice-9 session)
   :use-module (ice-9 readline))

(export car)
(export caar)
...
(export list)
(export-syntax define)
(export-syntax if)
...

(define-public (open-file name mode)
...
)

(define-module (my-safe-schme)
	:norootmodule
	:use-module (safe-scheme))
; Here in this module we can now only perform operations
; we consider safe, but not e.g load-module, set-current-module etc
; which would be too powerful, as a lot of other stuff which is
; hard to have control over.
;;;;;;;;;;;;;;;

"Marisha Ray & Neil Jerram" <mpriz@dircon.co.uk> writes:
> Defining a module which exports only safe names seems back-to-front to me.
> I would suggest that
>     - core Guile should not contain any potentially unsafe operations
>     - unsafe stuff like file ops goes into separate modules
>    - we need some kind of security mechanism (similar to Java's
> SecurityManager and ClassLoader?) to vet the modules that the interpreter is
> allowed to use.
> The security mechanism sounds restrictive, but I think we need only apply it
> to modules that have a C component.

Sorry, but these comments above for me sounds just insane.
When you say:
>     - core Guile should not contain any potentially unsafe operations
So, any file operations should be removed from core scheme then?

>     - unsafe stuff like file ops goes into separate modules
and WHO would be considering and deciding what operations are safe and
when. You may have very different requirements of security depending on
application. In one application you could allow for a limited set of
file operations but in another you may only allow some controlled 
operations on sockets. 

> The security mechanism sounds restrictive, but I think we need only apply it
> to modules that have a C component.
What do you mean by that? Most things I do have a C-component and guile
is built by these C-components and as soon as you e.g load a module you
may load several C-modules as well.

What you speak about sounds like something which would be very very hard
to administer and have control over.

We already have a powerful module system which is now also being improved 
(rewritten?) by Jost and by defining security as modules you can
have a very strict and precise control of your security needs.

For instance, different hierarchical security levels can simply be
implemented by just having several modules which import the more
restricted modules.

	Best regards
	Roland Orre

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]