Encasementlib treats all args as security layers

[yyzhuang]

When we want to specify an arg to a security layer, encasementlib mistakenly thinks the arg is another security layer.

`start dylink.r2py encasementlib.r2py sensor_layer.r2py restrict_battery.r2py -- -s 10 nanny_battery_test.r2py

......
User traceback:
"dylink.r2py", line 547, in
"dylink.r2py", line 408, in dylink_dispatch
"dylink.r2py", line 521, in evaluate
"encasementlib.r2py", line 242, in
"encasementlib.r2py", line 227, in secure_dispatch
"dylink.r2py", line 521, in evaluate
"sensor_layer.r2py", line 250, in
"encasementlib.r2py", line 177, in _secure_dispatch_closure
"encasementlib.r2py", line 227, in secure_dispatch
"dylink.r2py", line 521, in evaluate
"restrict_battery.r2py", line 37, in
"encasementlib.r2py", line 177, in _secure_dispatch_closure
"encasementlib.r2py", line 221, in secure_dispatch
"encasementlib.r2py", line 77, in _layer_code
Exception (with class 'exception_hierarchy.FileNotFoundError'): Cannot load security layer '-s'. File not found.`

Here -s is an arg to security layer restrict_battery.r2py.

[JustinCappos]

Said differently, if a security layer wants to have its own arguments, if
needs to remove those from callargs (or similar) in the encasement library.

We need this to be documented in a clear way and tested.

On Wed, Jul 29, 2015 at 3:03 AM, Yanyan Zhuang notifications@github.com
wrote:

When we want to specify an arg to a security layer, encasementlib
mistakenly thinks the arg is another security layer.

`start dylink.r2py encasementlib.r2py sensor_layer.r2py
restrict_battery.r2py -- -s 10 nanny_battery_test.r2py

......
User traceback:
"dylink.r2py", line 547, in
"dylink.r2py", line 408, in dylink_dispatch
"dylink.r2py", line 521, in evaluate
"encasementlib.r2py", line 242, in
"encasementlib.r2py", line 227, in secure_dispatch
"dylink.r2py", line 521, in evaluate
"sensor_layer.r2py", line 250, in
"encasementlib.r2py", line 177, in _secure_dispatch_closure
"encasementlib.r2py", line 227, in secure_dispatch
"dylink.r2py", line 521, in evaluate
"restrict_battery.r2py", line 37, in
"encasementlib.r2py", line 177, in _secure_dispatch_closure
"encasementlib.r2py", line 221, in secure_dispatch
"encasementlib.r2py", line 77, in _layer_code
Exception (with class 'exception_hierarchy.FileNotFoundError'): Cannot
load security layer '-s'. File not found.`

Here -s is an arg to security layer restrict_battery.r2py.

—
Reply to this email directly or view it on GitHub
#172.

[aaaaalbert]

Compare with this security layer that just pops from callargs:

https://github.com/aaaaalbert/benchmark_repy_v2/blob/master/mutarg-seclayer-init.r2py#L6-L7

[aaaaalbert]

OK, security layers that take a fixed number of arguments can just modify the callargs list accordingly.

Layers that take a variable number of arguments can perhaps steal the idea described in aaaaalbert/repy_v2@577526e: Use -- to signal a change in the target for the next couple of args.

For the "firewall" layer mentioned in the automatic reference above, I could then use things like

x@y !> start encasementlib.r2py firewall.r2py 10--8 -- user_program.r2py
x@y !> start encasementlib.r2py firewall.r2py 10--8 192.168--16 -- user_program.r2py
x@y !> start encasementlib.r2py firewall.r2py 10--8 192.168--16 -- another_layer.r2py singlearg user_program.r2py user_program_arg

(Another, less beautiful, way to solve this would be to not allow any callargs to security layers, but use config files instead.)