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