Fedora to (try to) remove setuid files for F15

Posted Nov 8, 2010 7:07 UTC (Mon) by solardiz (guest, #35993)
Parent article: Fedora to (try to) remove setuid files for F15

For the curious, I dispute Fedora's plan in some detail and I suggest alternatives here:

http://www.openwall.com/lists/oss-security/2010/11/08/3

to post comments

Fedora to (try to) remove setuid files for F15

Posted Nov 8, 2010 7:24 UTC (Mon) by dlang (guest, #313) [Link] (4 responses)

disputing one point in your article.

one very good reason for having someone login as themselves and then su/sudo to root rather than just logging in as root is that it gives you some sort of idea who it was that became root (it's not perfect because someone may have walked away from an unlocked screen, but it's a whole lot better than 'anyone with a root password could have done this')

yes, you could create root equivalent accounts for everyone, but that's a lot of extra passwords and accounts to manage.

Fedora to (try to) remove setuid files for F15

Posted Nov 8, 2010 8:48 UTC (Mon) by solardiz (guest, #35993) [Link] (3 responses)

Thank you for the feedback. As you have noticed, I actually addressed the accountability issue by proposing multiple root accounts. That's an approach we (the sysadmin teams I'm on) use since late-1990s, and it's working very well - at least no worse than non-root accounts + su would in this respect.

No extra passwords and no extra accounts to manage. It would be a security risk for a sysadmin to share a non-root account for su'ing to root and for other uses (a lot of people do just that, but it's plain wrong to take the unjustified risk, in my opinion). Thus, there would have to be _two_ non-root accounts per person. With our approach, this is replaced with one root-privileged account and one non-root account. (Also, SSH keys are used instead of passwords in most cases. And it is OK to use the same keypair for root and non-root.)

Fedora to (try to) remove setuid files for F15

Posted Nov 8, 2010 8:56 UTC (Mon) by dlang (guest, #313) [Link] (2 responses)

we have different criteria for what's acceptable.

I don't see anything fundamentally wrong with using the same account to launch su and to do other things, and I see a major problem with using the same SSH keypair for different purposes.

Fedora to (try to) remove setuid files for F15

Posted Nov 8, 2010 9:25 UTC (Mon) by solardiz (guest, #35993) [Link] (1 responses)

It could be different criteria, but I've actually seen security compromises propagate from non-root to root due to use of su or sudo while also using the same non-root account for other purposes and/or logging in to it from more places.(*) I haven't seen any security compromises that I could attribute to SSH keypair reuse for root and non-root on the same target machine.

(*) I've also seen security compromises propagate from one server to another via scp/sftp/ssh invoked _from_ a server.

What specific major problem do you see with using the same SSH keypair for root and non-root on the same target system? I do see how using different keypairs - only with different and very strong private key passphrases - would potentially improve security a little bit if the "root keypair" is extremely rarely used. But that sounds like more of an exception than the typical case, especially when one has to co-administer many servers. There's simply no other sane choice than to accept some SSH keypair reuse. We typically opt to use one SSH keypair per person per target network or target project:

http://openwall.info/wiki/internal/ssh

Fedora to (try to) remove setuid files for F15

Posted Nov 9, 2010 3:40 UTC (Tue) by cras (guest, #7000) [Link]

I'd think you can create a poor man's su/sudo by simply creating a new SSH key, adding it to root's allowed_keys and use "alias sudo ssh -i ~/.ssh/id_dsa.root root@localhost". sudo-style password remembering can be done by ssh-agent.

BTW. I like your way of getting rid of setuid binaries more. That's actually what I thought F15's plan was when I first read the headline, but then got disappointed.