Control: unarchive -1 Resending to get it in the BTS. ----- Forwarded message from Bas Wijnen <wijnen@debian.org> ----- Date: Mon, 17 Mar 2014 03:43:01 +0100 From: Bas Wijnen <wijnen@debian.org> To: Colin Watson <cjwatson@debian.org> Cc: Thijs Kinkhorst <kink@squirrelmail.org>, 298138@bugs.debian.org, Matthew Vernon <matthew@sel.cam.ac.uk> Subject: Re: Bug#298138: ssh: PermitRootLogin should defaul to "no" On Sat, Mar 05, 2005 at 02:20:41PM +0000, Colin Watson wrote: > On Sat, Mar 05, 2005 at 02:26:45PM +0100, Thijs Kinkhorst wrote: > > On Sat, March 5, 2005 02:41, Matthew Vernon said: > > > Please read README.Debian before submitting your bug reports - this is > > > good practice for any package, not just ssh. > > > > You're absolutely correct, I should have done that, sorry. You're very polite, which is very nice especially compared to how users are treated for this issue. But this is not correct; you should check reported bugs (which may be marked WONTFIX) before reporting a bug. Reading README.Debian is not at all a requirement. That's where you expect to find specifics about using the Debian package (particularly how it is different from upstream), not arrogant messages preemptively telling you to not bother the maintainer. > > If you permit, I'd like to ask a question about this. To me, the text in > > README.Debian is not clear on the following point: how is allowing root > > login just as secure as not allowing that? > > Note that OpenSSH upstream ship with PermitRootLogin switched on as > well. This isn't a Debian-specific change. It's a good idea to fix it there as well then. However, Debian doesn't just copy what upstream is doing; if we know better, we do it better. > > You write: > > "If you set it to no, then they must compromise a normal user > > account. In the vast majority of cases, this does not give added > > security; remember that any account you su to root from is equivalent > > to root - compromising this account gives an attacker access to root > > easily." > > > > As I understand this, the hacker has to do the following to gain superuser > > privileges. > > > > PRL-on: > > 1. Know the root password. > > PRL-off: > > 1. Compromise a normal user account (one that allows su-ing). > > 2. Know the root password or a local root exploit. > > Much easier: compromise a normal user account, install a keylogger, and > wait for that user to su to root. As long as you have an account which > is privileged in this way, you should treat it with the same care as you > treat your root account, since it is ultimately equivalent to root with > only a little work. So you're saying there is a different attack possible which is still more work than simply knowing the root password. I don't see how this leads to the conclusion that PermitRootLogin set to yes is not less secure. > "PermitRootLogin no" often buys only the illusion of security, and > we'd rather people thought about the issues a little more carefully > than that. Then you better well tell them about it in a way that they cannot possibly miss, before they even install the package. Real-life example: I set up a single-user machine and used a totally insecure root password. I'm not interested in protecting the system, only in protecting my own account[1]. My thought was: they'll need to get into my account before they get to root, and if they have my account I don't care about root anymore. But of course I did not expect the ssh package to be so insecure as to let people remotely log in as root. Because who would ever want that? And who would ever expect it to be the default? I was lucky that I had a break-in soon, before I had any important data on the machine, and by a very stupid person, so I instantly detected it. You can't expect everyone to be that lucky. You're putting our users at risk for no good reason. Please stop. [1] http://xkcd.com/1200/ > Providing the illusion of security without > providing real security is dangerous, since (in this case) it encourages > people to use effectively root-equivalent user accounts as if they were > unprivileged: "they must have turned PermitRootLogin off for a reason". Please explain how anything gets more secure from allowing people to log in remotely as root. Your argument that root is an easy target from a user account doesn't in any way mean that root should be made a target through other means as well. All my data is in my user account. You've added an attack vector by opening up a second login which has access to it. That would be sort of acceptable if I would expect it. But I have no reason to, and therefore you shouldn't do it. Please set PermitRootLogin to false by default. Thanks, Bas ----- End forwarded message -----
Attachment:
signature.asc
Description: Digital signature