linux-kernel - Re: Q: selinux_bprm_committed_creds() && signals/do

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <20090501000222.8BACEFC3BF@magilla.sf.frob.com>
Date:	Thu, 30 Apr 2009 17:02:22 -0700 (PDT)
From:	Roland McGrath <roland@...hat.com>
To:	Oleg Nesterov <oleg@...hat.com>
Cc:	David Howells <dhowells@...hat.com>,
	Eric Paris <eparis@...isplace.org>,
	James Morris <jmorris@...ei.org>,
	Stephen Smalley <sds@...ho.nsa.gov>,
	linux-kernel@...r.kernel.org
Subject: Re: Q: selinux_bprm_committed_creds() && signals/do_wait

The SIGNAL_GROUP_EXIT check is fine for now.  But we should revisit this
area more thoroughly at some point.  (That is a low-priority thing.)

There is a wrinkle here I don't like.  The fatal signal is "committed to"
(sender approved by security modules, etc.) "before" the exec, but gets
delivered "after" the exec.  e.g., acct_process() writes a record for the
killed process showing the uid/gid from after the setuid/setgid exec, when
security would not have allowed the killing signal to be sent after the
exec, only before.  Obviously this is a minor quirk (not to be worried
about today), but it points to a deeper kind of "wrong" that troubles me.
I can't think of any other similar wrinkles that could be observable at
all (or matter more than that one), but there might be another.

This is related to the issue of racing stop signals lost by de_thread().
That is still on our back-burner list to think about more deeply one day.
We don't need to contemplate any of this much more right now, but I would
like to address the whole mess better later on.

I don't understand why install_exec_creds() is called as late as it is.
Can't we do that in flush_old_exec()--you know, where it says:
	/* install the new credentials */
?

What I think would be best is if flush_old_exec() does all the "point of no
return" logic and that includes the credentials changes.  Then we can
define this as the point of transition from "before exec" to "after exec".
It would do the final check for signals interrupting the exec, and if
flush_old_exec() returned 0, then any "new" signals are "after exec".
We'd reorganize things so the final creds switch is under siglock.
Then either a sender precedes the exec and any security module's flushing
logic wipes the pre-exec state as it wants to, or the sender follows the
exec and is subject to signal security checks based on the new credentials.

Thanks,
Roland
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/