Rewrite parts of firejail in Rust

[rusty-snake]

Rewrite parts of firejail (namely profile-parsing) in Rust.

Pros

• Parsing strings in Rust is friendlier than in C because it has more function and
• You don't need to worry about memory-safety while parsing string
• Implementing complexer parsing logic like Support bash or AppArmor like variables #3424/Support bash like alias #3412, private-etc templates #1734, Replace whitelist and blacklist commands with better terms #3447, Support subpaths in macros (like ${PICTURES}/Screenshots) #2359 is much easier.
  Just compare

  if (strncmp(line, "blacklist ", 10) == 0) {
      foo(line+10);
  }

  with

  if let Some(path) = line.strip_prefix("blacklist ") {
      foo(path);
  }

Cons

• New dependency on Rust

What do you think? Is this something we should follow?

[glitsj16]

FWIW I can definately see the interesting features of Rust for profile parsing. As to the con of a new dependency personally I wouldn't mind. Rust seems to be very well supported and rustup is a great way to add it to an OS that doesn't offer Rust via native package management tools. Then again, my opinion isn't worth much, I don't get to decide stuff like this and that's fine :-)

[curiosityseeker]

I 'm not a programmer but think it's certainly a good idea in order to produce safe code. There are some projects that help to convert C code to Rust:

https://github.com/immunant/c2rust
https://github.com/NishanthSpShetty/crust

One question: does anybody have a clue which Firejail vulnerabilities in the past would have been prevented by Rust?

[rusty-snake]

I can not remember any memory-safety bug in firejail.

[rusty-snake]

With #4656 this is becoming interesting again. Did you know that void * works like that?

#![feature(c_size_t)]

use std::os::raw::*;

extern "C" {
    fn write(fd: c_int, buf: *const c_void, count: c_size_t) -> c_ssize_t; 
}            

fn main() {
    const HELLO_WORD: &[u8; 14] = b"Hello, World!\n";
    unsafe {
        write(1, HELLO_WORD as *const _ as *const c_void, HELLO_WORD.len());
    }                                      
}

rustc +nightly --edition=2021 -O void_ptr.rs

[matu3ba]

I like the idea, but feel like Rust ecosystem has often overboarding amounts of dependencies which makes code reusage hard.

Implementing complexer parsing logic

How much parsing did you do in Rust so far?

Pros

+- frameworks do not support tracing a parse, because that requires macros on every function, which makes compilation time very big. (though last time I checked ca. 1 year ago)

Cons

• big binary size makes linking slow. in every build. (rust also has no incremental linking)
• writing manually error formatting and so on is really annoying. alternative of using macros slows down compilation time, since macros in Rust are very slow.
• semantic correctness becomes harder with a bigger grammar semantics (testing is required) => Are the extensions just syntactic sugar?
• poratbility?

Providing aliases, variables, macros sounds like providing a complete DSL and macros are a rather brittle and error-prone abstraction,
since macros make inspection of logic harder on every level of indirection.
What is the decision criteria of "how much comlpexity is too much complexity"?

[rusty-snake]

I like the idea, but feel like Rust ecosystem has often overboarding amounts of dependencies which makes code reusage hard.

TBH we should not use any third-party crates (except of libc) for code that is linked in firejail (the firejail binary itself). For other programs (e.g. fbuilder or firecfg) we can use some third-party crates IMHO. For my own project I always try to keep the amount of dependencies (and dependencies of dependencies) minimal. I never said to use cargo 😉, we can use meson (which has a rudimentary rust support) or call rustc directly.

How much parsing did you do in Rust so far?

firejail profiles for example.

Providing aliases, variables, macros sounds like providing a complete DSL

Actually we only need

1. Conditional lines
   • We already have ?HAS_NOSOUND: <...> like conditions.
   • I would like to see ?HAS(<line>): <...> too.
2. Aliases (i.e. alias nofoo = "blacklist /tmp/foo && blacklist /run/foo) which are not hardcoded. noprinters is an example for an hardcoded alias. Hardcoded aliases just increase the size of firejail and can not be changed after compilations (e.g. for workarounds). These aliases do not need to be supported in profiles, a /etc/firejail/aliases file is fine.
3. Not hardcoded (but maybe static) substitutions of arguments (i.e. private-etc foo,@network,bar)

That's the complexity that firejail profiles have/need IMHO. If that a DSL then this is the way it is.

We have objected $(exec shell command and capture stdout) like sytax in the past. Not sure about getenv(var) syntax.

and macros are a rather brittle and error-prone abstraction,
since macros make inspection of logic harder on every level of indirection.

We have already macros (${HOME}, ${PATH}, ...)

writing manually error formatting and so on is really annoying.

Is C better here?

macros in Rust are very slow ...

... but very very powerful.

+- frameworks do not support tracing a parse, because that requires macros on every function, which makes compilation time very big. (though last time I checked ca. 1 year ago)

• semantic correctness becomes harder with a bigger grammar semantics (testing is required) => Are the extensions just syntactic sugar?

😕 WDYM

[matu3ba]

firejail profiles for example.

LGTM then.

?HAS():

Relative positioned content breaks, if you run python script to reorder/format profiles.

alias nofoo = "blacklist /tmp/foo && blacklist /run/foo

Aliases etc are fine, if you can not nest them.

We have objected $(exec shell command and capture stdout) like sytax in the past. Not sure about getenv(var) syntax.

At what point is it easier to provide programmatic access to "static for the lifetime of firejail (configuration)" configuration objects?

macros

As I understand it, macros are user-definable and usable, ie macro m1=/home/user/git and usage with something like whitelist macro m1. Recursive substitution of macros can be very painful, if no conventions with sufficient lengths exist.

Is C better here?

No.

tracing a parse

When you have a (PEG) grammar, you can annotate every rule with a number. The parsing code can log those numbers (conditionally).
This helps fuzzing nested stuff, estimating test coverage etc.

extensions just syntactic sugar

kinda redundant to "At what point is it easier to provide programmatic access to "static for the lifetime of firejail (configuration)" configuration objects?"

[SkewedZeppelin]

Is anyone interested in doing this if sponsored?

Either rewriting parts of it or creating a profile compatible reimplementation?

[SkewedZeppelin]

Related:
@rusty-snake what is the state of your various CrabJail projects?

[rusty-snake]

• crabsecco: Ready for use.
• fire-run: Started as "replace firejail with 15 lines of bash" but I couldn't manage xdg-dbus-proxy to work yet.
• crabjail/jailconfs: Come from the high end to make sandboxing as easy as possible without knowing much details about the OS-APIs. The version is intentionally 0.0.x i.e. don't use it yet for production. The development has become a bit stale ATOW.
• crablock: Started as experiment with Landlock (hence the name) but got a lot more features and more are to come (including xdg-dbus-proxy support). It comes from the lower end and you need know details about your OS to proper use it. It's like a "better" (subjective term) bubblewrap.

[amano-kenji]

I don't like Rust. On gentoo linux, building rust is a pain in the ass because gentoo has to build packages without network access.

If I had to build multiple rust components in firejail, I may not be able to build firejail on gentoo linux.

Gentoo linux already downloads anki binary because anki depends on python rust wheels and npm for build.
Gentoo linux used to build anki from source.

Don't make build process complex.

If you are going to write some components in rust, build everything in one rust project, and produce a smaller binary with rust. If profile parsing was split into a rust binary, gentoo can still build firejail. If firejail has to build multiple rust binaries, gentoo may need to start downloading firejail binary.

[amano-kenji]

Rust also has the issue of dependency hell. It is better than npm, but a rust project has to include all transitive dependencies. It is ugly. If some dependencies aren't fetched from crates.io, I have to manually write such dependencies in gentoo package build script. It is a pain.

If a rust project doesn't follow a standard structure, I may have to write hundreds of transitive dependencies in my gentoo package build script. Doing that over several versions of a rust program was enough to make me hate rust.

[rusty-snake]

Already addressed in #4386 (comment).

we should not use any third-party crates (except of libc) for code that is linked in firejail (the firejail binary itself).

I never said to use cargo 😉, we can use meson (which has a rudimentary rust support) or call rustc directly.

[kmk3]

@rusty-snake commented on Oct 11:

Implementation

Do we want all this message passing and parsing in C? Or Rust? #4386

Since this is a very isolated feature in the code base, it would be a good
feature to bring in rust without touching FFI topics.

Some of the main appeals of firejail to me is that it is written in C, is
relatively simple/small (and fast to build) and has little to no dependencies.
From what I've seen so far, Rust seems to be closer to the other end of the
spectrum with regards to complexity/portability/build time, so I'm not really
interested in learning/debugging it or dealing with its toolchains/ecosystem.

Also (and this part more subjecitve I suppose), usually I can make sense of the
source code of languages with C-like syntax (such as Perl/Python/Lua, etc)
without having prior experience with them. While Rust's syntax looks very
terse/"operator-heavy" and from occasionally reading comments about the borrow
checker, my impression is that it seems to expose its
language-/implementation-internals a bit too much (in a way similar to C++), in
the sense that it seems to be not too uncommon having to fight with the
compiler to achieve the desired behavior, even for what appear to be mundane
tasks by the standards of general-purpose languages.

Ultimately, the additional complexity and reduced portability seem like a high
price to pay for extra safety compared to C. The price also seems expensive
for extra performance compared to using an interpreted/garbage-collected
language (such as Perl/Python/Lua).

I think that compared to C, Rust targets a different kind of audience, in the
sense of how much more they prioritize performance and memory safety compared
to everything else (such as simplicity, stability and portability).

So (maybe save for big and/or complex projects) it doesn't seem to make much
sense to have both C and Rust in the same codebase (as they are kind of in the
same realm of being compiled, static and focused on performance), compared to
having a single main language (such as C or C++ or Rust) plus a
helper/scripting language to deal with the parts that are not
performance-critical. Having a simpler secondary language could not only add
safety to such parts, but would probably make them easier and faster to
read/write/debug and prototype.

In other words, it seems like it would make much more sense to create a
separate Rust-based implementation (like with crabjail) and reap all of the
memory safety benefits and what not pervasively than to pay all of that price
upfront (and to then have to deal with the idiosyncrasies of both C and Rust in
the same codebase) for only adding safety incrementally/only on some binaries.

As for using a helper/scripting language, I'll post that in a separate comment.

---

Edit: Posted in a new discussion:

• Add Lua as an extension language to firejail #5417

[matu3ba]

functional compiled languages

I would not consider Haskell very portable and it is more of a pain regarding compilation performance. OCaml sounds okayish, but getting native C-like performance requires more maintenance and the code becomes much more convoluted.

nim

I can not tell much about performance, but I do not see the point yet of transpiling to C for compilation.

zig

I am biased here. The self-hosted compiler is still unstable, but the bpf bits are in libstd ziglang/zig#10717 and typing is very strict unless explicitly escape-hatched. The Zig compiler is designed with DOD in mind (minimal REPL turnaround time) and most widely known projects are for high-perf stuff (bun, mach), but it also creates the smallest binaries.

vlang

Isnt vlang also transpiling to C and even less mature?

Is there any overview of priorities (portability, compilation performance, runtime performance, binary size, memory safety, no memory leaks, ease of developing low level, ease of performance tuning), ideally with some rough weighting ?
I dont see a list of all supported environments of firejail yet, so I dont understand, if supporting all targets and use cases of Linux is the goal (including embedded ones).

[amano-kenji]

native C-like performance

Do you really need C-like performance? firejail itself doesn't seem to do much calculation. Idiomatic OCaml should be fast enough for us to not notice difference in performance.

[rusty-snake]

I didn't checked anything, but a lot of firejails time will be syscalls and profile/command-line parsing.

---

nim vlang zig

No matter how good some of their concepts are, the are to small IMHO.

OCaml

Easier ? 😨

Compile Performance

firejail is small, very small. Even a double in compile time would still be fast.

ecosystem of language ...

We will not include third-party libraries in a SUID binary (standart library, appramor and selinux are exceptions).

Runtime performance

It does not have do be C performance (but it would be nice). I would say the limit should be somewhere between C and Java.

Haskell, OCaml, ...

Do they support Linux APIs in a easy way?

Any other language

How many devs do we have with knowledge in this language?

C: The most of use have at least basic knowledge
Rust: reinerh, I and maybe more
v-lang: likely nobody
zig: likely nobody

[amano-kenji]

OCaml is easier than Haskell. Haskell is easier than Rust.

OCaml and Haskell are going to be easier than C when you actually write programs.

Do they support Linux APIs in a easy way?

OCaml and Haskell support C FFI. Linux APIs are C APIs. You are probably going to need to write bindings for linux APIs.

Writing linux API bindings can be boring.

How many devs do we have with knowledge in this language?

I didn't take people's familiarity with languages into account. If you are going to rewrite firejail from scratch anyway, you can definitely learn a new programming language.

[topimiettinen]

The choice would be easy if most Firejail developers would be fluent also in new language X (or could easily become fluent), or if existing developers not fluent with language X could be replaced trivially with new ones who can maintain Firejail rewritten in X. I think none of those is possible for more obscure languages. Also I don't know how easily it's for someone like myself with C background can learn Rust. It's getting popular, so perhaps we could attract new developers.

Memory safety is a nice feature and performance isn't very critical with Firejail. So as a user, I'd prefer switching to Rust version, but as a developer with no Rust skills I'd rather contribute to the C version.