On Wed, 2004-04-21 at 15:21, Stephen Smalley wrote: > The only purpose of the newrole re-authentication is to force a user > interaction to verify user intent prior to a role change, as opposed to > some malicious code that happens to be run by the user being able to > change roles without the user's awareness. The policy governs who can > enter the role, not the newrole program. Anything could be substituted > for the re-authentication, as long as it provides some confidence of > user confirmation and is not easily spoofed by malicious code. Ok, that all makes sense. Why not then just use getpwuid(getuid()) instead of getpwnam? Hm, although I see one reason - on a SELinux system where "su" is not modified, and a normal user with their own SELinux user identity uses "su" to become uid 0, then uses newrole, they'd be prompted for the root password instead of their password. However for Fedora where we've modified "su", this is not an issue. > Long term, the right solution is to use a trusted path mechanism once one > becomes available in Linux. Yeah. It seems there is some work in this area going on: http://shellcode.org/Kernel/tpe/
Attachment:
signature.asc
Description: This is a digitally signed message part
