Whitelisting on /proc

[mardy]

Currently, the /proc tree can only be restricted by blacklisting individual paths. But with a blacklist, there's the risk that some kernel modules expose some sensitive information in nonstandard /proc/ files, so I'd rather whitelist the files that I know the application needs, rather than risking to give access to unforeseen files.

What is the reason for not allowing whitelisting on proc?

[rusty-snake]

What is the reason for not allowing whitelisting on proc?

First we have to split proc into two parts:

• /proc/<pid|tid>/* i.e. process information
• and /proc/sys, /proc/cmdline, ... i.e. system information

Nowadays kernel modules use sysfs if they need a apifs for systemwide things. It has a better/easier api in the kernel and is future proof. So system information in /proc root are a legacy thing caused by the initial days of Linux (and others) and are there to stay forever.

System information files are created during mount _simplified. The process information directories however are created dynamically on fork/clone/exit/... _simplified.

If your program only needs /proc/cpuinfo (and does not check the SUPER_MAGIC) whitelisting would work. However if any program in the sandbox ever needs /proc/<pid|tid|self|...>/* how do you want to whitelist it?

kernel modules expose some sensitive information in nonstandard /proc/ files

What do you mean? Do you use some scary third-party modules?

[mardy]

I was naively thinking that I could do:

whitelist /proc/1*
whilelist /proc/2*
...

to allow access to the PID paths, but indeed, that wouldn't work because it wouldn't see any processes that are created later inside the sandbox. Eh, I wish they had used /proc/pids/<pid> instead, that would have made things easier.

What do you mean? Do you use some scary third-party modules?

Not on my system, but mobile OSes sometimes rely on Android BSPs, and there the kernel and modules are pretty much up to the hardware vendor.

[rusty-snake]

that wouldn't work because it wouldn't see any processes that are created later inside the sandbox

You neither know the pids before nor do they even exist.

I wish they had used /proc/pids/ instead, that would have made things easier.

So your usecase is to hide system information i.e. subset=pid. Nor process information or pids.

[rusty-snake]

• Command to mount /proc with subset=pid #6491

[mardy]

I wish they had used /proc/pids/ instead, that would have made things easier.

So your usecase is to hide system information i.e. subset=pid. Nor process information or pids.

Well, not necessarily all, for backwards compatibility it could be fine to expose /proc/cpuinfo and a few others. Maybe we could allow whitelisting files by following an algorithm like this one:

1. mount the /proc from the PID namespace into our /proc (this hides all the PIDS outside of the sandbox)
2. Process the whitelist commands by just adding those paths to a list (do nothing on the filesystem)
3. Process blacklist commands as usual
4. Scan /proc (except for the PIDs subtrees) and blacklist all paths that are not in the whitelist and that have not been already blacklisted

This would not protect from proc files appearing later, but there's little we can do about those anyway.