> On 13 Jul 2026, at 13:10, Rony G. Flatscher <[email protected]> wrote: > > A few thoughts about the security manager: it exists to allow for supervising > running Rexx programs. There are sensible instructions/actions in the > language that could be exploited in a malevolent manner; one can mitigate > this by appointing a security manager to determine how to handle them. > > Sensible instructions/actions are calls to external routines or commands, > access to stream-related built-in functions (charin, charout, chars, linein, > lineout, lines, stream), requiring (calling) packages/programs, access to any > protected method, and access to the environment directories .local and > .environment. > > All of this has been working in ooRexx since its existence; ooRexx 5.0.0 > broke the supervision of static requires directives, and it still does not > work, which makes the whole concept of a security manager moot, it seems. > > Looking at the security manager-related APIs, there are three classes that > possess a setSecurityManager method: .routine, .package, and .method. How > about adding an optional new trailing "securityManager" argument to their > constructors? Supplying it would cause the supervision messages (CALL, > COMMAND, STREAM, METHOD, REQUIRES, LOCAL, ENVIRONMENT) to be sent to the > supplied security manager. Could that mitigate the situation regarding > REQUIRES? >
I don't know. Months ago, I worked on this, but I've forgotten most of the details. https://sourceforge.net/p/oorexx/mailman/oorexx-devel/thread/c728c239-9ac8-494c-b85d-5a38abe5ed31%40wu.ac.at/#msg59259308 I remember that a security manager at the interpreter level catches the ::requires. https://sourceforge.net/p/oorexx/patches/223/ That was a WIP, was interruped because of a recursion problem with a BSF test case. And that would probably reduce performance because all security checkpoints would be triggered everywhere. > --- > > Another concern is that the setSecurityManager method is not protected. This > allows a code block (from a routine, method, or package) to use it to > set/change, or remove a security manager. > Well, they are protected (P in col 7). ooRexx[sh]> ?m setSecurityManager P. P.GP. 'SETSECURITYMANAGER' : 'Method' (REXX) P. P.GP. 'SETSECURITYMANAGER' : 'Package' (REXX) P. P.GP. 'SETSECURITYMANAGER' : 'Routine' (REXX) > --- > > When experimenting with this ability (to change the security manager from > within the supervised code block), the following observations were taken: > > the security manager of the supervised code block wil get the supervise > messages CALL, COMMAND, STREAM, METHOD, REQUIRES (for dynamic requires > only!), LOCAL, ENVIRONMENT > > removing the security manager of the supervised code block by sending > ".context~executable~setSecurityManager": this affects the supervise messages > CALL, COMMAND, LOCAL, ENVIRONMENT, and STREAM, which do not get sent anymore. > However, the supervise messages METHOD, REQUIRES still get sent to the > originally set security manager, which seems to be a bug > > adding a new security manager to the code block by sending > ".context~executable~setSecurityManager(.allowAll~new)": this affects the > supervise messages CALL, COMMAND, LOCAL, ENVIRONMENT, which get sent to the > new security manager. However, the supervise message STREAM does not get sent > to it; the supervise messages METHOD, REQUIRES still get sent to the > originally set security manager, which seems to be a bug > So something is wrong when changing the security managers for code blocks > depending on the supervise messages: > > the original security manager for the supervise messages METHOD, REQUIRES > does not get changed > the supervise message STREAM, once the security manager got removed, does not > get re-established to a newly set security manager > --- > > It is interesting to note, and potentially a bug, that accessing some > environment symbols are not supervised (neither the LOCAL nor the ENVIRONMENT > supervise message gets sent), e.g. .Object, .true > I think that .True is no longer an environment symbol. > --- > > So there are different aspects in this context that need to be thought about, > checked and fixed. > > Any thoughts about this? Any comments, ideas how to proceed from here on? > > Also, how about the terminology used here (supervise messages that get sent > to a security manager), is it understandable, clearer, easier than the > current documentation? > Not sure... https://chatgpt.com/s/t_6a54e7f6c2fc8191b93392e26fcdf0f8 I tend to trust this kind of feedback, it's very helpful for me as a non-native English speaker.
_______________________________________________ Oorexx-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/oorexx-devel
