In an effort to be constructive here, I will attempt to break out specific, concrete permissions revoked at each SAFE level (or conversely, granted as SAFE levels are reduced). I base this on the publicly available edition of Programming Ruby (http://www.ruby-doc.org/docs/ProgrammingRuby/) under the chapter "Locking Ruby in the Safe", since I do not have a current copy handy.
I attempt to phrase these as they would be described in security documentation, with a proposed "permission" name for illustrative purposes.
These permissions would NOT necessarily be grouped as in the SAFE levels, other than for SAFE level compatibility. The user would be able to mix and match them at will, as with Java security policies.
Some permissions may imply other permissions must be granted.
I also omit restrictions relating to tainting, since I believe tainting is a fundamentally flawed mechanism of security.
From SAFE level 1:
- OptionsFromEnvironment - whether RUBYLIB and RUBYOPT are observed
- SearchCurrentDirectory - whether . is added to the load path. In 1.9 this one is moot, since . is not added to load path by default
- NonlocalScripts - whether -e -i -I -r -s -S and -x options are observed
- ExecFromWorldWritable - whether external commands can be executed if the directory containing them is world-writable
- EvalString - whether arbitrary strings can be evaluated. Either allow strings or do not; don't rely on tainting bits for "safety".
- LoadFile - whether external files can be loaded. Same argument regarding tainting.
- QueryIOStatus - whether IO channels' statuses can be queried or modified. (I'm not quite sure what "status" means in this context)
- ExecCommand - whether external commands can be executed.
- SignalTrap - whether signals can be trapped and handled.
From SAFE level 2:
- ManipulateDirectories - whether directories can be modified, changed into, or chrooted. Note that Java provides for file/dir permissions to be granted on a per-file or per-hierarchy basis, which is much more flexible. You grant access to what you want to allow access to.
- LoadFromWorldWritable - whether files can be loaded from directories that are world-writable.
- LoadFromHomeBase - whether files can be loaded from paths starting with ~.
- QueryFileStatus - whether methods like File.stat, File.umask can be used.
- ModifyFileStatus - whether methods like File.chown, File.chmod can be used. Java may have a better grouping of these operations, I'm not sure.
- ModifyProcess - whether methods like Kernel#fork, Process.setpgid, etc can be used.
From SAFE level 3:
NONE..the only restrictions at this level are related to tainting.
From SAFE level 4:
- ModifyGlobalVariable - whether global variables can be updated.
- AccessInstanceVariableExternally - whether methods like instance_variable_get can be used.
- ModifyEnvironmentVariable - whether ENV changes are permitted.
- CloseFile - whether already open files can be closed.
- OpenFile - whether new files can be opened.
- FreezeObject - whether objects not already frozen can be frozen.
- AlterVisibility - whether existing methods can have their visibility changed.
- AliasMethod - whether new method aliases can be defined.
- QueryMetadata - whether method and variable lists can be queried.
- DefineMethod - whether methods can be defined, redefined, removed, or undef'ed.
- ModifyObject - whether the Object class can be modified in any way. Perhaps includes top-level?
- ModifyInstanceVariablesExternally - whether instance variables can be modified or removed via instance_variable_set and friends.
- ModifyThread - whether currently running threads can be modified in any way.
- ModifyThreadLocalVariable - whether thread-local variables can be modified.
- TerminateThread - whether threads can be terminated from outside the thread itself.
- ModifyThreadGroup - whether threads can be removed or added to thread groups.
- ExitProcess - whether the current process can be terminated.
- IncludeModule - whether modules can be included into existing class hierarchies.
- WalkObjects - whether methods like each_object or _id2ref are allowed.
- WriteToIO - whether writes to IO channels are allowed.
- DefineAutoload - whether new autoloads can be defined.
This is just a rough example from 15 minutes of flipping the safe level documentation around a little. It's obviously not all-encompassing; there are things you might expect an attacker to do in untrusted code that aren't covered here. But hopefully it shows how the current safe levels could be broken into finer-grained permissions that users can assembly in any way they choose, and which different implementations can implement either in terms of VM restrictions or OS-level restrictions.
Updated by 
Updated by 
Updated by 
Updated by nahi (Hiroshi Nakamura) about 13 years ago
Updated by 
Updated by 
Updated by 
Updated by 
Updated by 
Updated by hsbt (Hiroshi SHIBATA) almost 10 years ago
Updated by k0kubun (Takashi Kokubun) about 6 years ago