Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Encasementlib treats all args as security layers #172

Open
yyzhuang opened this issue Jul 29, 2015 · 3 comments
Open

Encasementlib treats all args as security layers #172

yyzhuang opened this issue Jul 29, 2015 · 3 comments

Comments

@yyzhuang
Copy link

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
Copy link
Contributor

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 [email protected]
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
Copy link
Contributor

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 added a commit to aaaaalbert/repy-doodles that referenced this issue Nov 23, 2016
@aaaaalbert
WIP: Complete the "firewall" security layer
732a75f 
This commit adds the required `CHILD_CONTEXT_DEF`s for the security
layer. However, testing reveals that SeattleTestbed/seattlelib_v2#172
("Encasementlib treats all args as security layers") is still a problem:
Currently, the firewall layer assumes that you specify the subnets to
be filtered as callargs; `encasementlib` does not support this correctly.

(The question actually is whether `encasementlib` *could* support this
correctly at all --- from what I see, there is no way telling which
security layer in `encasementlib`s `callargs` should get which
command-line argument(s). We are probably better off just requiring a
sec layer config file for those layers that need configuration....)
@aaaaalbert
Copy link
Contributor

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.)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@JustinCappos @yyzhuang @aaaaalbert