On 1/3/2018 11:44 AM, Matthew Garrett wrote: > On Wed, Jan 3, 2018 at 11:32 AM, Casey Schaufler <casey@xxxxxxxxxxxxxxxx> wrote: >> On 1/3/2018 10:11 AM, Matthew Garrett wrote: >>> The problem here is that we don't *have* the task secid for one of the >>> cases I care about. Validating the task secid at execution time gives >>> us the security context of the spawning process, rather than the >>> spawned one - by the time it's committed to the task structure, it's >>> too late to block execution, so all we have is the secid associated >>> with the creds in the bprm structure. Obviously fixing this in a way >>> that doesn't break your work is important, so any suggestions on how I >>> should be fixing this? :) >> A security module is allowed to manage either or both of >> task and cred blobs. How a security module uses secids is >> completely up to the module. So far, everyone is using the >> secid to be an alias for the secctx, and the task and cred >> are treated as (roughly) the same kind of thing. But that's >> not guaranteed going forward. I don't know what someone >> might want to do that would cause a problem, but people are >> amazingly creative. >> >> I'm actually more concerned with the IMA code using the audit >> rule matching. There's an assumption that the secid from a >> cred and a secid from a task are both acceptable to the audit >> system. What if they aren't? It's possible that I'm just >> being paranoid, but we're getting too many permutations >> (audit/IMA + task/cred) for my liking. > The idea here is that we want to be able to trigger an IMA rule > conditionally based on the LSM context a process is running under at > exec time. The current code does so using the secid of current, which > means we're determining whether the new binary should be measured > based on the security context of the task that's executing it. > However, we want to be able to do so based on the security context of > the task that's being executed (usecase here is that I want to measure > anything that's executed in a privileged security context, but don't > care about anything that's running in an unprivileged context). The > child secid has been calculated and put in the creds that are present > in the bprm structure, but commit_creds() hasn't been called yet and > as a result they're not associated with the task struct. One of the > outcomes of measurement may be to block execution, and unfortunately > by the time commit_creds() has been called it's too late to do so. > > If we want to be able to do something conditional on the LSM context > that a process is going to be executed under, *before* commit_creds() > is called, is there an existing way to do so? I can rework this so we > use the task secid for all running processes and the cred secid for > the not-yet-running child process, but I don't know if that's > sufficient to avoid problems in future. It's possible that converting all the existing calls of security_task_getsecid() to security_cred_getsecid() is the safe approach. No one is using the task blob today, and this would disambiguate the situation.
