Introducing cap-std, a capability-based version of the Rust standard library
51 views
Skip to first unread message
Alan Karp
Jun 23, 2021, 7:41:08 PM6/23/21
to cap-...@googlegroups.com
Valerio Bellizzomi
Jun 24, 2021, 9:16:48 AM6/24/21
to cap-talk
As I said before, the Intel Cloud Hypervisor is written in Rust, so I would expect future cloud systems to benefit capability security.
On Thursday, June 24, 2021 at 1:41:08 AM UTC+2 alan...@gmail.com wrote:
Valerio Bellizzomi
Jun 24, 2021, 9:29:00 AM6/24/21
to cap-talk
and btw, I just started a new discussion on the topic at the Rust github page:
Dan Connolly
Jun 26, 2021, 2:24:32 AM6/26/21
to cap-...@googlegroups.com
Yes; this rust-std stuff is fantastic. It addressed a rust issue I've been tracking since Oct 2012: https://github.com/dckc/rust/issues/2 Least Authority rust std/core libs
I knew about rust-std for a while, but the part that's news to me recently is the taming database and static analysis tool (clippy plug-in):
I tried to do some advocacy around this stuff; I don't think I convinced the person I was exchanging comments with, but perhaps I influenced some others: https://lobste.rs/s/rlwby3/introducing_cap_std_capability_based
--
You received this message because you are subscribed to the Google Groups "cap-talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cap-talk+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/cap-talk/28814a02-ed0e-4412-9c27-9065474bc20fn%40googlegroups.com.
Dan Connolly
Mark S. Miller
Jun 26, 2021, 7:09:10 AM6/26/21
to cap-...@googlegroups.com
Where is that sibling thread that this thread refers to?
To view this discussion on the web visit https://groups.google.com/d/msgid/cap-talk/CAD2YivZYEH%2B5vn43g07AtwmYP-QVDh_CPg16XjiJ%3D6Vi7AgmUg%40mail.gmail.com.
John Kemp
Jun 26, 2021, 7:50:38 AM6/26/21
to cap-...@googlegroups.com
I have to admit, I am a little mystified by this.
OK, as a programmer, I can now more easily enforce myself writing code without ambient authority to the filesystem. But isn’t the actual threat is that someone else writes bad or evil code, and it gets loaded onto my computer?
For Javascript, loading libraries and taming them during execution via SES, makes some sense because of the web platform.
I imagine that they might be thinking about Rust->WASM, but wouldn’t the right place to do this work, be in the thing that executes the WASM?
- johnk
To view this discussion on the web visit https://groups.google.com/d/msgid/cap-talk/CAD2YivZYEH%2B5vn43g07AtwmYP-QVDh_CPg16XjiJ%3D6Vi7AgmUg%40mail.gmail.com.
Tony Arcieri
Jun 26, 2021, 2:05:27 PM6/26/21
to cap-...@googlegroups.com
On Sat, Jun 26, 2021 at 4:50 AM John Kemp <stable.p...@gmail.com> wrote:
OK, as a programmer, I can now more easily enforce myself writing code without ambient authority to the filesystem. But isn’t the actual threat is that someone else writes bad or evil code, and it gets loaded onto my computer?
The problem cap-std aims to address is preventing things like directory traversal / local file disclosure attacks resulting from some sort of bug in a network service.
These are exceedingly common and don't require RCE to pull off (but can often be exploited to achieve RCE by exfiltrating secrets needed to compromise a host)
--
Tony Arcieri
Matt Rice
Jun 26, 2021, 4:57:00 PM6/26/21
to cap-talk
A bit of the discussion Dan was involved in revolves around taming the
compiler itself,
Rust's compilation model itself is intertwined with its execution
model. To compile source code, you must first compile and execute a
file called build.rs, so it will
will compile + execute a process. Further there are "procedural
macros" which compile to a shared library then the compiler itself
will dlopen that shared library and
call some entry point into the procedural macro. Both these cases can
generate source code which will subsequently be compiled to form the
compilation output.
Fancy IDE's like to check your source code and helpfully display
errors in it, which entails all of the above. Lately they want to do
this when you merely open a file,
and a likely way in which developers read sources to discover whether
they actually trust the code in question. I think many people
rightfully believe opening some source code shouldn't imply
execution of processes written by the source author or any dependency therein.
There are projects like Watt, to run proc macros in wasm,
https://github.com/dtolnay/watt
And the author of the cranelift compiler backend has had a sporadic
but multi-year effort to compile the rust compiler to, and run it in
wasm.
https://github.com/bjorn3/rust/tree/compile_rustc_for_wasm4
The rust std library when compiled for various platforms are not all
alike, rusts std library for WASI (a wasm implementation) lacks much
of the ambient authority which the compiler relies on),
and so porting it is a somewhat painful exercise. I haven't followed
the effort to compile rustc to wasm to have a good estimate at how
much of the port would overlap with a cap-std implementation...
(alternately said, how much of a rustc ported to cap-std would "just
work", when compiled to wasm). Given the similar limitations of
cap-std to the std impl provided for WASI, (and assuming the future
work on std::process,
and the "Speaking of WASI" aspects of the blog post). It seems likely
to me though that it would lessen the effort for porting rustc to run
on wasm,
along with other capability architectures which in the future could
have an implementation of cap-std... while also running natively on
non-capability OS's and at the very least, not being in any worse of a
security situation than these compilers are currently.
I don't place much faith in the people going through the effort to
actually audit sources, when I don't believe anyone should trust the
tools they might be using to actually read those sources,
no matter how much I trust the person performing the audit to not act
maliciously...
> To view this discussion on the web visit https://groups.google.com/d/msgid/cap-talk/255376A4-89ED-4953-B260-3F18CACCA93D%40gmail.com.
compiler itself,
Rust's compilation model itself is intertwined with its execution
model. To compile source code, you must first compile and execute a
file called build.rs, so it will
will compile + execute a process. Further there are "procedural
macros" which compile to a shared library then the compiler itself
will dlopen that shared library and
call some entry point into the procedural macro. Both these cases can
generate source code which will subsequently be compiled to form the
compilation output.
Fancy IDE's like to check your source code and helpfully display
errors in it, which entails all of the above. Lately they want to do
this when you merely open a file,
and a likely way in which developers read sources to discover whether
they actually trust the code in question. I think many people
rightfully believe opening some source code shouldn't imply
execution of processes written by the source author or any dependency therein.
There are projects like Watt, to run proc macros in wasm,
https://github.com/dtolnay/watt
And the author of the cranelift compiler backend has had a sporadic
but multi-year effort to compile the rust compiler to, and run it in
wasm.
https://github.com/bjorn3/rust/tree/compile_rustc_for_wasm4
The rust std library when compiled for various platforms are not all
alike, rusts std library for WASI (a wasm implementation) lacks much
of the ambient authority which the compiler relies on),
and so porting it is a somewhat painful exercise. I haven't followed
the effort to compile rustc to wasm to have a good estimate at how
much of the port would overlap with a cap-std implementation...
(alternately said, how much of a rustc ported to cap-std would "just
work", when compiled to wasm). Given the similar limitations of
cap-std to the std impl provided for WASI, (and assuming the future
work on std::process,
and the "Speaking of WASI" aspects of the blog post). It seems likely
to me though that it would lessen the effort for porting rustc to run
on wasm,
along with other capability architectures which in the future could
have an implementation of cap-std... while also running natively on
non-capability OS's and at the very least, not being in any worse of a
security situation than these compilers are currently.
I don't place much faith in the people going through the effort to
actually audit sources, when I don't believe anyone should trust the
tools they might be using to actually read those sources,
no matter how much I trust the person performing the audit to not act
maliciously...
Alan Karp
Jun 26, 2021, 5:08:30 PM6/26/21
to cap-...@googlegroups.com
A minor correction. You don't need build.rs. Also, macros manipulate tokens of an AST and expand to source code that gets compiled with the rest of your program.
Disclaimer: I've been programming in Rust for several years and have never used build.rs or written any macros.
--------------
Alan Karp
--------------
Alan Karp
To view this discussion on the web visit https://groups.google.com/d/msgid/cap-talk/CACTLOForG_Tn26PNsLf7%3DwJvjdqzmY_99-1V2YLibuGXQOGdKg%40mail.gmail.com.
Matt Rice
Jun 26, 2021, 5:15:48 PM6/26/21
to cap-talk
Thanks, I should have said something like "build.rs if it exists", I'm
mostly worried about some unsuspecting Joe who doesn't know to
actually look,
and might rightfully not suspect that the act of opening source code
involves running executables...
> To view this discussion on the web visit https://groups.google.com/d/msgid/cap-talk/CANpA1Z3_fxzTcqnmHxsZh74%3DSRjj-BO5wa1g%2BEUPG0jr0Dp48g%40mail.gmail.com.
mostly worried about some unsuspecting Joe who doesn't know to
actually look,
and might rightfully not suspect that the act of opening source code
involves running executables...
Valerio Bellizzomi
Jun 29, 2021, 12:01:45 PM6/29/21
to cap-talk
Somebody among Intel Cloud Hypervisor developers seems interested in adopting cap-std, some historical doubt is haunting him, how can we help?
Message has been deleted
Valerio Bellizzomi
Jul 25, 2021, 12:16:06 PM7/25/21
to cap-talk
Follow-up on my questions:
Reply all
Reply to author
Forward
0 new messages