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.

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

mkdir and whitelist enhancements #1130

Open
msva opened this issue Mar 6, 2017 · 6 comments
Open

mkdir and whitelist enhancements #1130

msva opened this issue Mar 6, 2017 · 6 comments
Labels
enhancement New feature request

Comments

@msva
Copy link
Contributor

msva commented Mar 6, 2017

It will be nice if directives like whitelist/mkdir/blacklist/noblacklist (and so on) support variables like ${USER} and ${UID}, and also allowed to use them "in-line" (look below).

For example, firefox uses /tmp/mozilla_mva0 as temp download dir (to download files, for opening in external programs) on my system.
Here, mva is a username of system user running firefox.
I'd very like to whitelist (and mkdir, since it can to not exist at the time firefox starts) it, but it seems to be impossible without hardcoding username...

Also, it is paths like /run/user/1000/<...>. And in some cases I'd very like to hide /run from application (so it can't see foreign pids, sockets and so on), but allow it to use some sockets under /run/user/<uid>/

So, I'd like to use

mkdir /tmp/mozilla_${USER}0
whitelist /tmp/mozilla_${USER}0 # Actually, a bit cooler solution would be `/tmp/mozilla_${USER}[0-9]*`

for first case, and

noblacklist /run
whitelist /run/firejail # security issu, in my opition, but jail doesn't work otherwise
whitelist /run/user/${UID}/pulse

for second.

===

Also, it will be nice to have regex/pcre support for the path-related directives (as I mentioned above, things like [0-9] can be useful, but much more useful thing in the paths is wildcards).
mkdir can (and probably should) not support expressions in last particle (since it is useless), but it should support them for 0 to pre-last particles.

===

Also, you mentioned in one of the previous issues, that you have plans to allow all paths under / be whitelist'ed.
And that's great!
But they also should be allowed to be mkdir'ed, blacklist'ed (especially /run), and so on.

Thanks for the attention :)

@netblue30 netblue30 added the enhancement New feature request label Mar 7, 2017
@netblue30
Copy link
Owner

You can blacklist individual files or directories under /run today:

$ firejail --blacklist=/run/initramfs/
Reading profile /etc/firejail/default.profile
Reading profile /etc/firejail/disable-common.inc
Reading profile /etc/firejail/disable-common.local
Reading profile /etc/firejail/disable-programs.inc
Reading profile /etc/firejail/disable-passwdmgr.inc

** Note: you can use --noprofile to disable default.profile **

Parent pid 4942, child pid 4943
Child process initialized
$ ls /run/initramfs
ls: cannot open directory /run/initramfs: Permission denied
$ 

To blacklist /run is not possible, this is where firejail keeps its runtime data. I'll add support to whitelist /run. I can add mkdir support in /tmp directory, but not in other places. The directory will be created as the regular user starting the sandbox. I'll look into extending regx support.

@netblue30 netblue30 changed the title [feature] path-related directives: support for variables, expressions, ANY (not restricted to hardcoded lists) paths mkdir and whitelist enhancements Mar 7, 2017
@msva
Copy link
Contributor Author

msva commented Mar 7, 2017

To blacklist /run is not possible, this is where firejail keeps its runtime data.

So, I guess, allowing whitelisting /run (as any other dir in /) and auto-whitelisting /run/firejail will do the trick...

<...> mkdir <...> The directory will be created as the regular user starting the sandbox.

How about making it possible in general, but disabled by default (as you did for symlinks in private-bin)? And also forbid to enable it in user's configuration (only in system-wide config)

I agree, that it can be potentially dangerous (although, I do not see the exact unavoidable flaw), but it is also situations where it can be useful (especially for the soft that wants to be run as root), and some users can take responsibility for their actions :-D.

I'll look into extending regx support.

Thanks!
// and don't forget about variables, please ;) As I initially mentioned, it is good to whitelist /tmp/mozilla_${USER}0 directory (even in default Fx profile), but it is impossible without hardcoding username.
And same for /run/user/${UID} condition.
Or even /tmp/tmux-${UID}. And it it tons of examples where it can be useful ;)
Thanks in advance ;)

@netblue30
Copy link
Owner

I added support for mkdir under /tmp directory. You can try it out.

How about making it possible in general, but disabled by default (as you did for symlinks in private-bin)? And also forbid to enable it in user's configuration (only in system-wide config)

For private-bin the symlinks already exist, and is assumed root user put them there. The problem is allowing the regular user to create directories as root.

I'll add /run to whitelist options. What other directories would you need?

@msva
Copy link
Contributor Author

msva commented Mar 7, 2017

ok, let's forget about mkdir for now, and talk about whitelist:
For whitelist, I think it should be possible to set any path. You can't predict filesystem paths user decided to use on his/her fs: it can be anything:
/usr/* for hiding /usr stuff (compilers, linkers, includes and many other info) except for needed one, or
/data, /system and so on on androids,
Or there is CoreOS and its friends with totally different filesystem hierarchy.

So, as I said, it can be absolutelly any random path that user might want to whitelist for some reasons.
So, I'd ask you to not hardcode every single condition in fj's sources, but just allow to whitelist everything under /. Anyway, I can't imagine how it can be used for bad.

@msva
Copy link
Contributor Author

msva commented Mar 7, 2017

Also, a bit offtop: am I missing something, or there is no option like touch or something like it? Expected behaviour is like mkdir, but create empty files, but not directories. Would be useful in situations:

  1. target for bind'ing (while file doesn't exist on host system)
  2. target for blacklist'ing (to pretend like file do exist, but is unavailable because of 'Permission denied') also, for cases where file doesn't exist on host system

@netblue30
Copy link
Owner

am I missing something, or there is no option like touch or something like it?

Use "mkfile" in profile files.

Until I figure out the random whitelisting, I'll add support for /run and /usr.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature request
Projects
None yet
Development

No branches or pull requests

2 participants