xref: /minix3/minix/fs/procfs/NOTES (revision 433d6423c39e34ec4b79c950597bb2d236f886be)
1Development notes regarding ProcFS. Original document by David van Moolenbroek.
2
3
4SECURITY MODEL
5
6Right now, procfs is not able to deal with security-sensitive information,
7because there would be too many opportunities for rogue processes to obtain
8values they shouldn't be able to get to. This is mainly due to the fact that
9while procfs is running, the environment around it may change arbitrarily: for
10example, a /proc/<pid>/mem file could offer access to a process's core memory,
11but if a rogue process opened that file right before the victim process invokes
12an exec() on a setuid binary, the rogue process could read from the victim
13process's memory while a victim user provides this process with their password.
14This is only one example out of many; such time-to-check/time-to-use race
15conditions are inherent to the inherently race-prone situation that procfs
16finds itself in, trying to provide information about an asynchronously running
17system.
18
19A little more specifically, this problem mainly comes up when system calls are
20made to obtain information (long) after a certain PID directory has been
21updated, which typically happens right after pulling in a new copy of the
22process tables of the kernel, PM, and VFS. Returning stale information from
23those tables is usually not a problem: at worst, the caller gets outdated
24information about the system as it once was, after passing a security check for
25that point in time. Hence, it can not obtain information it never had access
26to. Using information from those tables to perform calls later, however, is
27a different case. In the "mem" example above, procfs would have the old user ID
28in its copy of the process tables, and yet perform on-demand sys_datacopy calls
29(or something similar) to retrieve memory from the process, bypassing a check
30on the then-current user ID. A similar situation already exists right now for
31the /proc/<pid>/map file for example, which pulls in information on demand -
32but it provides only public information anyway, just like the other files that
33procfs currently exposes.
34
35A proper solution to this problem has simply not been implemented yet. It is
36possible to change the system in such a way that procfs check whether the
37target process is still in the same security state before returning information
38to the caller process. This can be done either while or after obtaining the
39information, depending on what is most convenient for the design of the system.
40Any such solution obviously has an impact on system design and procfs'
41performance, and was found not worth implementing for the first version of
42procfs, since all offered information was public anyway. However, such a change
43*must* be made before procfs can expose anything that provides a potential for
44security breaches.
45
46Finally, it must be kept in mind that even updating the process tables from
47various other sources is not an atomic operation. There might be mismatches
48between the tables. Procfs must be able to handle such occurrences with care,
49from both a security perspective and a general functionality perspective.
50
51
52FUTURE EXPANSIONS
53
54It would be trivial to add a /proc/self symlink pointing to the caller's PID
55directory, if the VFS-FS protocol's REQ_RDLINK request were augmented to
56include the caller's PID or endpoint. However, this would be a procfs-specific
57protocol change, and there does not seem to be a need for this just yet.
58
59Even more custom protocol changes or procfs-specific backcalls would have to be
60added to expose processes' current working directory, root directory,
61executable path, or open files. A number of VFS parts would have to be changed
62significantly to fully support all of these, possibly including an entire DNLC.
63
64All the necessary infrastructure is there to add static (sub)directories - for
65example, a /proc/net/ directory. It would be more tricky to add subdirectories
66for dynamic (process) directories, for example /proc/<pid>/fd/. This would
67require some changes to the VTreeFS side of the tree management. Some of the
68current assumptions are documented in type.h.
69