Ticket #1500 (new RFC)

Opened 4 years ago

Last modified 3 years ago

API to tell which opcode group an opcode is in

Reported by: dukeleto Owned by: whiteknight
Priority: major Milestone:
Component: core Version: master
Severity: medium Keywords: security
Cc: Language:
Patch status: Platform: all

Description (last modified by dukeleto) (diff)

I am currently hacking on PL/Parrot and one of the very important features that we need is disallowing certain operations, most notably file I/O. The motivation for this is that you do not want a stored procedure written in PIR to be able to modify the database via disk operations.

I talked with chromatic in #parrot about needing some security subsystem features and he agreed that we need an API for telling if an opcode is in a particular opcode group. This is talked about in PDD18 if you want to get the full background.

For instance, take the open opcode:

inline op open(out PMC, in STR, in STR) :filesys_open {
/* etc... */

It is defined to be in the "filesys_open" opcode group. Currently there is no way to tell if a certain opcode is in a given group. The information does not seem to make it into op_info_t, but it is in lib/Parrot/OpLib/core.pm . I propose a public C API that will consist of at least these three functions:

Parrot_sec_opcode_is_in_group(string opcode_name, string group_name)

This function would take an opcode name and opcode group name as argument and return true if the opcode is in the group, false otherwise.

Parrot_sec_opcodes_in_group(string opcode_group)

This function takes a string argument of an opcode group name and returns a ResizableStringArray containing all opcodes in that group.

Parrot_sec_groups_containing_opcode(string opcode_name)

This function takes a string argument of an opcode name and returns a ResizableStringArray listing all groups that contain the given opcode name.

Once an API in C is available to accomplish these things, then it should be straight forward to access this information from PIR.

Change History

Changed 4 years ago by dukeleto

  • priority changed from normal to major
  • description modified (diff)

Changed 3 years ago by whiteknight

  • keywords security added
  • owner changed from dukeleto to whiteknight
  • version changed from 2.1.0 to master

Is a C API what we really want most here, or would methods on the Opcode and OpLib PMCs suffice? That is, is the ultimate goal to have this information available from PIR, or do we really want it available at the C level? Both?

Changed 3 years ago by dukeleto

Well, I originally wanted the API to be from C, so that embedding applications could access it, but it seems that if we can do it all from PIR, that would be sufficient, since a C app could just load the appropriate PIR/PBC that does this stuff.

Changed 3 years ago by whiteknight

Looking at the generated opcode source, I don't see that this group information is kept around. The open opcode isn't core anymore, but even in the generated C code of the dynoplib we don't seem to keep that information available anywhere. I'm not really sure how we want to try to expose the information if it's not currently being kept.

Also, are there a fixed number of groups so we could do something like a bitfield, or are group names arbitrary and would need to be kept around in strings?

Note: See TracTickets for help on using tickets.