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

IPC security - Allow policy targets to be symlinks #1173

Merged
merged 6 commits into from
Apr 16, 2017

Commits on Apr 16, 2017

  1. Configuration menu
    Copy the full SHA
    cf5e764 View commit details
    Browse the repository at this point in the history
  2. Configuration menu
    Copy the full SHA
    b4357a8 View commit details
    Browse the repository at this point in the history
  3. Configuration menu
    Copy the full SHA
    bfb9923 View commit details
    Browse the repository at this point in the history
  4. Configuration menu
    Copy the full SHA
    bcf9338 View commit details
    Browse the repository at this point in the history
  5. Configuration menu
    Copy the full SHA
    c9694ee View commit details
    Browse the repository at this point in the history
  6. Handle symlinks as IPC security targets

    - When policies are allocated, the ipc target path goes
      through symlink resolution. The result is used as
      the canonical for matching pids to policies at runtime.
      In particular, this matches up with the target of
      the `/proc/<pid>/exe`.
    - There's a possible race condition if this isn't done
      correctly, read below.
    
    Originally, validate_ipc_target() always tried to resolve
    its argument for symlinks, and returned a parogram target string
    if it validates. This created a possible race condition with
    security implications. The problem is that get_feature_policy()
    first independently resolved the policy target in order to check
    whether a policy already exists. If it didn't find any, it called
    alloc_feature_policy() which called validate_ipc_target() which
    resolved the policy target again. In the time between the two
    checks, the symlink could be altered, and a lucky attacker could
    fool the program into thinking that a policy doesn't exist
    for a target, and then switch the symlink to point at another file.
    At the very least this could allow him to create two policies
    for the same program target, and possibly to bypass security
    by associating the permissions for one target with another,
    or force default permissions to apply to a target for which
    a more specific rule has been configured. So we don't that.
    
    Instead, the policy target is resolved once and that result is
    used for the rest of the lookup/creation process.
    JerziKaminsky committed Apr 16, 2017
    Configuration menu
    Copy the full SHA
    2ad8850 View commit details
    Browse the repository at this point in the history