Bug 967385

documented root passwd leaves the machines open to remote root login by anybody. its reccomended to login as liveuser and use sudo.

Live images have always had an empty root password though. sshd was simply disabled (and if enabled, it won't allow logging in with an empty password). I see no discussion anywhere for that change.

And using sudo isn't any more secure because liveuser has no password either.

https://access.redhat.com/security/cve/CVE-2013-2069 is what is was fixed for. the code is shared for livecds and appliances. It wont be getting changed. using sudo with liveuser means a single account has to be compromised to elevate permissions. with an unlocked root any account can be compromised to become root. its a matter of one attack vector vs many attack vectors.

For now this is in fact fixed, by https://git.fedorahosted.org/cgit/spin-kickstarts.git/commit/?h=f19&id=94d8808a138085238b7e9053aec194bbabc6aa43 . That was committed/pushed by me but in fact submitted to the spins ML by bcl when he first 'fixed' the CVE in livecd-tools. See https://bugzilla.redhat.com/show_bug.cgi?id=964299#c7 .

If Dennis feels strongly that this should be considered a security issue even for the generic Fedora live images and we should no longer have an unlocked root account on the lives, then we can consider reverting that, but I don't believe this outcome was the intent of the CVE. It was considered a 'security issue' for appliance images, not for the Fedora live images. It is correct to 'fix' the issue in livecd-tools, but it is legitimate and expected to have the Fedora live image kickstarts unlock the root account, IMHO.

Note that the sshd on the live images is not enabled by default and, even if enabled manually, does not allow access to the root account unless you set a password on it. I have checked this.

AIUI, the 'typical use case' for Fedora live images is considered to be transient use, and anyone who uses them in persistent mode is expected to tweak their configuration accordingly.

Oh, and if we're going to make the 'security' change for the Fedora live images I strongly feel that at this point we should do it for F20, not F19, to give more time to catch any problems with it. Even if it is to some degree a security problem it's the way we've shipped live images forever and the only way we are sure actually _works_. Given how hoary our live image infrastructure is I would be worried that, if we just changed this now for F19 and fixed the most 'obvious' problems that show up in consequence (e.g. liveinst doesn't work any more), we would miss slightly less obvious but still significant problems.

Doing it for F20 gives us much longer to catch any consequences of the change.

we have also always shipped the appliances that way forever. we should change any call to su with sudo for liveinst. we really shouldn't have ever shipped this way. i think it was only not considered a security issue for lives because they were not considered. i think we should seek the input of the Red Hat security team.

Sure, but we haven't been shipping the appliances as long, and we didn't explicitly consider this when setting them up initially, we just built off the existing live image infrastructure. In contrast, the lives *were* explicitly designed to work this way.

I'm not saying that just because we picked one design a decade ago it must definitely be the right design and can't possibly have any security issues, but I am saying the live and appliance cases are rather different and we shouldn't just assume the same design/approach is appropriate for both, and I'm also saying there is a danger to changing this quite quietly, quite late in the F19 cycle for the Fedora live images.

Personally, my view point is that this is _not_ a security flaw in the Fedora live CD given the "typical transient use-case".  Having said that, it's also not so black and white.  People use live CDs for more than just testing to see if Fedora will work on their system and while sshd may prevent password-less root logins, unless you are willing to audit every other conceivable daemon that a user _might_ start on a live CD (and provided by/on the same) you can't really use that argument.  sshd was not permitting root access to password-less accounts either on the appliances yet it was deemed to be a real enough threat based on what users _might_ do with them (and other software, besides sshd, that could/would run on them).

The same can be said for live CDs.  Yes, I understand that the typical use-case of an appliance vs a live CD differs in most cases, but I don't believe it can be said that this will _never_ be an issue.

And since we're not really preventing the local user from being root regardless (via sudo), then I do not see the harm in locking the root account in a way that prevents _any_ access to it except via sudo.

My point of view is that this is not a security flaw to be fixed, but a necessary security hardening that really should be implemented sooner rather than later.  If you're adamant (and the rest of the Fedora steering committee or other folks who make decisions feel the same), then I am ok with deferring this to Fedora 20 _provided_ that a very large warning is presented when the system boots and it is documented as such.

Password-less and unlocked root accounts are bad.  This has been demonstrated.  Is the issue as severe in this case?  No -- based on typical usage.  But since we can't imply that typical == common sense, then it would be better to err on the side of caution and lock the account than to find out later that someone did something clever and then we find that we actually do have a security flaw on our hands, when it could have been trivially and sufficiently hardened against.

Did anyone think this was a problem in appliances before?  No.  And we were wrong.  I'd prefer not to make the same mistake again.

"and the rest of the Fedora steering committee or other folks who make decisions feel the same"

I'm not on any steering committees, I'm just an asshole on the internet with an opinion. We can escalate this to FESCo, or we can make a decision by consensus (or by git edit wars, because y'know, that's always fun!) and let it stand till someone else escalates it to FESCo or whatever.

I applied the patch on the understanding that this was considered a problem only for the appliance images and everyone agreed the change was never meant to apply to the live images; since this isn't the case, obviously, we should re-consider the way forward. On balance I'd prefer to ship F19 the way we shipped Fs1 through 18 and do the hardening in F20, but obviously, I'm unlikely to be entirely uninfluenced by my area of responsibility. If everyone who's currently expressed an interest is OK with doing it that way, we can do that; if the rest of you would all prefer to harden this in F19 and hope we catch any breakage it causes, I'll knuckle under and go with that. If there's something more like a 50/50 split, we'll probably have to take it up to FESCo.

This has never been a problem before, why is it considered one now? Because Amazon reported it? Because someone decided to give it a CVE ID? So if I don't like a design decision in software, I just need to report it as a "security issue" and get a CVE ID for it? (I guess I should request a lot of CVEs for GNOME then. ;-) )

IMHO, we should not change this. It is common knowledge that liveuser and root both have no password by default on Fedora live images. If you don't like it, set a password.

Just my 2 cents as another "asshole on the internet with an opinion". ;-)

One thing you'll definitely break by disabling root login is kdesu and anything that uses it.

My concern is that this isn't well documented (not anywhere I or Google can find), nor during system boot up or once I login am I notified that the root password is blank, nor am I prompted to password the root account. So this strongly violates the principle of least surprise. Now the good news is that if I click install to HD the "root password is not set" link is on top, and I am forced to set it before it proceeds, so that's good. However locking the account would prevent a lot of potential issues on the livecd, and doesn't impact anything functional (e.g. you can login as the live user and then get to root).

(In reply to Kevin Kofler from comment #10)
> This has never been a problem before, why is it considered one now? Because
> Amazon reported it? Because someone decided to give it a CVE ID? So if I
> don't like a design decision in software, I just need to report it as a
> "security issue" and get a CVE ID for it? (I guess I should request a lot of
> CVEs for GNOME then. ;-) )
> 
> IMHO, we should not change this. It is common knowledge that liveuser and
> root both have no password by default on Fedora live images. If you don't
> like it, set a password.
> 
> Just my 2 cents as another "asshole on the internet with an opinion". ;-)

Speaking as the person who initially decided to give this issue a CVE (as confirmed by a large number of other people at Red Hat) I would ask you to please check your facts on this issue before commenting. I assigned CVE-2013-2069 because, to quote:

https://bugzilla.redhat.com/show_bug.cgi?id=964299

The livecd-tools package provides support for reading and executing
Kickstart files in order to create a system image. It was discovered
that livecd-tools gave the root user an empty password rather than
leaving the password locked in situations where no 'rootpw' directive
was used or when the 'rootpw --lock' directive was used within the
Kickstart file, which could allow local users to gain access to the
root account.

Not because of some "design decision" I disliked. It should be noted however that (sufficiently bad) design decisions can qualify for CVEs.

> and doesn't impact anything functional

It does. It breaks all KDE apps using kdesu.

My opinion is that it's easy enough to set the password if you need that functionality ("sudo passwd" is all you need to do).  As Kurt indicated, this isn't documented anywhere that I can find either so I have my doubts that this was initially a design decision (but if you can back up that it was, please point me to where this is documented as intended behaviour), but rather a "meh" moment.  Well, there were plenty of "meh" moments with the appliance images until it was demonstrated that this actually a really bad thing (and no, it's not just because Amazon said it was).

Conversely, it's easy enough to disable the root account once you login _if_ you know that it's unlocked and without a password.  However, in the interest of good security policies, we tend to go for as much "secure by default" as possible which in this case means locking the account, and those who require it to be unlocked can take the 2-3s to unlock it, not forcing the people who do want to be "secure by default" to set the root password or lock the root account.  This is, as Kurt mentioned, the principle of least surprise.

> This has never been a problem before, why is it considered one now? Because
> Amazon reported it? Because someone decided to give it a CVE ID? So if I

At one point no one thought poorly-implemented temporary file handling was a problem either.  Clearly that is a problem, though, and there are a number of CVEs assigned that demonstrate as much.  So the argument of "it was never a problem before" doesn't really fly.  And temporary file handling is just one of many examples of issues that no one thought would amount to much.

I would rather err on the side of caution, strive to be secure by default, and prevent any possible issues down the road.  If this means that a person who needs to use kdesu has to take a few seconds to set the password, then I think that is an acceptable trade-off.

As I said last night, I'm not so tied up in this that I would arbitrarily revert Adam's git commit right now.  I would like to see something in place for Fedora 20 that locks the root account by default and perhaps has a startup dialog that asks for a root password to set during boot (with a timeout if none is provided, but which would then default to a locked account).  But leaving it like this indefinitely is silly.  It's like providing SELinux but disabling it by default.  Do we do that?  I'm pretty sure that we don't (because if the end-user wants a less secure system, they should have to work for it -- they shouldn't have to work for a reasonably secure system anymore).

> At one point no one thought poorly-implemented temporary file handling was a
> problem either.  Clearly that is a problem, though, and there are a number of
> CVEs assigned that demonstrate as much.

And the real problem in that case is the shared /tmp, and we still aren't doing anything about that by default. (Instead, we have silliness such as putting /tmp on tmpfs, but still shared for all users, which breaks just as many apps and doesn't bring us anything.)

> If this means that a person who needs to use kdesu has to take a few seconds to
> set the password, then I think that is an acceptable trade-off.

It is not. In most cases, users don't even see they are using kdesu, they only see the GUI prompt asking them for the root password. If the account is locked, they'll get an error instead and they won't understand why. And running the app under sudo instead is not an option because KDE apps don't work under sudo (nor plain su, for that matter). (They don't find a D-Bus session bus to connect to and abort, and even the crash reporter aborts for the same reason.) We could try to apply the Kubuntu patches for better sudo support, but last we checked, they had nasty side effects.

> It's like providing SELinux but disabling it by default.  Do we do that?

No, but we should! SELinux keeps breaking things and does not provide any functionality (by design: all it ever does is prevent things, not enable them). Even after YEARS of development, we still get weekly selinux-policy updates fixing things that were being forbidden by mistake. And the policy is very very far from even covering all of Fedora, it only covers a small list of targets, and the more it grows, the more regressions which require those weekly selinux-policy updates get introduced. I fail to see any sort of convergence, nor do I see it happening any time soon. A centralized policy trying to second-guess what the whole code in all of Fedora is trying to do just does not and will never scale.

I'm so fed up of evergrowing usability regressions in the name of "security".

I agree with Kurt and Vincent. The right way to do things in the future is to lock root by default and make sure liveinst works without needing any further user intervention.

If it is a simple enough fix I'd support doing it for F19, and sooner is better.

Also, this isn't a tools issue. It should be implemented in spin-kickstarts.

Kurt, comment #13:

"The livecd-tools package provides support for reading and executing Kickstart files in order to create a system image. It was discovered that livecd-tools gave the root user an empty password rather than leaving the password locked in situations where no 'rootpw' directive was used or when the 'rootpw --lock' directive was used within the Kickstart file, which could allow local users to gain access to the root account."

That's not really a response to Kevin's point, is it? Kevin's question was essentially "does this actually enable some kind of attack against typical users of Fedora that we were not previously aware of?" The above paragraph is essentially just a description of the 'bug', it is not a description of any actual consequences it has. "which could allow local users to gain access to the root account" is not a consequence, exactly, it's the _original intent_ of not setting a root password: the whole point is that we _want_ local users to gain access to the root account in the live environment. We _need_ them to.

This was a 'design decision' back in the days we did not have PK integration or even a great sudo implementation, so the only practical ways to have a usable live image at all would be to write some kind of wizard to set a root pw on boot, to use a pre-set root password, or just to leave the account unlocked.

Given the arguments above I'd now be in favour of changing this, but given what KK has said, I still think F20 is the time to be doing it. KDE is one of our supported desktops, it is required to work properly. We've had a nice, relatively churn-free F19 cycle so far, and I'd really hate to spend the Final phase trying to convert KDE to PolicyKit in two weeks or something.

I think the thing that's making KK and I kick is that this is not a case where someone's discovered some unintentional behaviour we didn't know about that causes a security problem, it's more that someone discovered some perfectly intentional behaviour we knew all about - the root account on live images is unlocked so live users can perform root actions and apps that require root privs like anaconda and all of KDE's systemwide config tools can work - and re-described it in the language of security advisories ("It was discovered
that livecd-tools gave the root user an empty password rather than leaving the password locked in situations where no 'rootpw' directive was used", as if this was inadvertent and previously unknown) so it can have a CVE slapped on it and suddenly be treated as a dire emergency.

Rather than address anything specific (as this bug is now very long), here is how this should work from the security perspective.

The default behavior of the tools should be "secure by default". That means we lock the root account.

If it's decided that no root password is the ideal way this should work (I see no real problem using no password on live images, if you have access to insert a CD or USB drive, you have access to do whatever you want), you remove the root password via kickstart.

The existing behavior of the livecd tools is correct. No password by default is bad, no password by design *can* be OK.

Just document what and why things are done (in this case, a kickstart comment).

josh: sure, I agree, and that is the current status in F19, now. The generation tools are now 'secure by default', and the live spin kickstarts explicitly unlock the root account.

root login works on 20130529 nightly images.