#249 safeScope Mutability breaks confinement

Need_for_security
closed-fixed
9
2005-07-24
2005-07-18
No

FIXED
At
http://www.eros-os.org/pipermail/e-lang/2003-November/009256.html
Kevin Reid reports:

leakage.emaker:
if (safeScope.maps("leakage")) {
safeScope["leakage"] += 1
} else {
safeScope.bindOuter("leakage", settable.makeSlot(1))
}
`Executed ${safeScope["leakage"]} times.`

? <import:leakage>
# value: "Executed 1 times."

? <import:leakage>
# value: "Executed 2 times."

? <import:leakage>
# value: "Executed 3 times."

-----------------

This problem break E's confinement. Until it is fixed, E
cannot claim to support locally untrusted code. The problem
is that, in transitioning to Dean's Transformer, Scopes
(i.e., reified environments) became extensible. By itself
this isn't a problem, but the safeScope itself includes
a binding from the name "safeScope" to the safeScope
itself. This violates the rule that the safeScope may
only contain transitively immutable objects. As Kevin
shows, this violation can be used as a communications
channel among subsystems that were supposedly confined.

Followups

Comment Date By
Finally fixed. The safeScope is once again immutable,
as it was before we had this bug. 2004-Jul-04 20:26 markm
Finally fixed. The safeScope is once again immutable,
as it was before we had this bug. 2004-Jul-04 20:26 markm
Finally fixed. The safeScope is once again immutable,
as it was before we had this bug. 2004-Jul-04 06:50 markm

Discussion

  • Steve Jenson

    Steve Jenson - 2005-07-18
    • status: open --> open-fixed
     
  • Steve Jenson

    Steve Jenson - 2005-07-18
    • status: open-fixed --> closed-fixed
     
  • Mark Samuel Miller

    • assigned_to: nobody --> caplet
     

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:





No, thanks