On Mon, May 26, 2014 at 6:27 AM, Djalal Harouni <tixxdz@xxxxxxxxxx> wrote: > Add the deny or allow flags, so we can perform proper permission checks > and set the result accordingly. These flags are needed in case we have > to cache the result of permission checks that are done during ->open() > time. Later during ->read(), we can decide to allow or deny the read(). > > The pid entries that need these flags are: > /proc/<pid>/stat > /proc/<pid>/wchan > /proc/<pid>/maps (will be handled in next patches). > > These files are world readable, userspace depend on that. To prevent > ASLR leaks and to avoid breaking userspace, we follow this scheme: > > a) Perform permission checks during ->open() > b) Cache the result of a) and return success > c) Recheck the cached result during ->read() > d) If cached == PID_ENTRY_DENY: > then we replace the sensitive fields with zeros, userspace won't > break and sensitive fields are protected. > > These flags are internal to /proc/<pid>/* Since this complex area of behavior has seen a lot of changes, I think I'd really like to see some tests in tools/testsing/selftests/ somewhere that actually codify what the expected behaviors should be. We have a lot of corner cases, a lot of userspace behaviors to retain, and given how fragile this area has been, I'd love to avoid seeing regressions. It seems like we need to test file permissions, open/read permissions, contents, etc, under many different cases (priv, unpriv, passing between priv/unpriv and unpriv/priv, ptrace checks, etc). If we could do a "make run_tests" in a selftests subdirectory, it'd be much easier to a) validate these fixes, and b) avoid regressions. -Kees -- Kees Cook Chrome OS Security -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
