1. The person answering you, here and also above, is not the same as the person (mjg) who writes this blog. I'm just another reader, like you.
2A. Part of the reason that I felt the urge to be facetious was because your posting included some embedded assumptions. There is no frustration on my part with the 'community mgmt' side of this bug, because a) the bug is not in my code, and b) the community is not my own, in the sense you imply -- I neither develop Mir, nor use it, as yet (ditto for wayland as yet). I can assume much the same of mjg, though perhaps it is better to let him speak for himself: he does not work on mir, nor for canonical... he used to work for redhat, and nowadays mostly reverse-engineers proprietary bios stuff, from what I can tell. We are both interested in the Mir project, and in how canonical will handle it in the future, because we both care about the future of Linux.
2B. However, the *main* reason that I was somewhat facetious in my answer is because I thought your question was too incomplete to answer properly (which I suppose is unworthy of me in some realm of politeness... but if I do not express frustration then how would you realize there was even a problem, albeit a minor one, in the first place?) You did not specify what you meant by "typical user". You did not specify what you meant by "does some work". You did not specify any details about your concerns, that would allow me to give you a correct and non-facetious answer. See also, ESR's guide to smart questions. So, I gave you a somewhat facetious answer, starting with the statistically typical user, who is running win8, and cursing their luck.
3. Your longer explanation of your personal situation gives me enough clues to answer your real question: will this bug in Mir impact *you* given the way you work? No, you are safe. Even if you are running the pre-13.10 distro of some sort, with Mir and Xmir installed from universe, as the title of the mjg blogpost clearly says, this security problem only impacts people that use VTs, aka Ctrl+Alt+Fwhatever, *and* have chat-sessions running foreground in their Xmir session. You run chat sessions, you have Xmir (or perhaps are still thinking about testing it), but you don't use VTs.
4A. For your own edification, and anybody else reading the comments later, I'll give the concise overview of How Many Ways Can I Get To The Command Line Under Ubuntu, subject to limitations on my own knowledge. Nowadays, when you boot a desktop Linux distro, you immediately start working in Unity under X -- in other words, the GUI. There is a shortcut, which I believe is ubuntu-specific, where you hit Ctrl+Alt+t which opens up a window, inside which you see a command line prompt, where you can type command lines stuff, like grep and ls and all the other traditional Unix-like commands from the 1970s. This is not the only way to open such a thing: you can also hit the winkey, type xterm, and hit enter. More or less the same thing happens, although the details under the hood differ slightly (and the background color may differ as a visual indicator of what is happening). Normally, those are the only ways that the typical ubuntu enduser will interact with a cmdln.
4B. Of course, that's not the only way to get cmdln access. Assuming your machine has an sshd server running, an a known IP address (or even a domain name), you can usually walk away from your desktop, open up an ssh client on some other machine (ssh on Linux or PuTTY on windows or whatnot), and connect back to your desktop securely. You don't see the GUI portion of your desktop Ubuntu this way, unless you are doing ssh tunneling of a VNC connection or somesuch, but you do get cmdln access. Remotely! Nice.
4C. Walking back to your ubuntu PC again, and hit Ctrl+Alt+F4, and something Completely Different will happen. Your screen will change from 1080p mode down to something like an 80x25 vt100-style display-mode, and you will have stark white text (in an ugly font) on a stark black background. Welcome back to 1969: this is more or less how Kernighan and Richie logged into their original UNIX boxen. These are the VTs that were mentioned. By default, they are loaded when the kernel boots, and most endusers never need them, or indeed are even aware they are there. We used F4, so we're in VT#4. You can also switch over to VT5, which is a different login-session (logged out by default just like VT4 was). Your beautiful Unity & X stuff is not gone, by the way -- just hit Ctrl+Alt+F7 to return to the GUI session. You can think of the VTs as a primitive sort of "tabbed" xterms, more or less. They are mostly used as a last-resort fallback, when the X session is hung, and you need to get into the cmdln to restart everything, or something like that. Handy, if you are debugging a problem in Xmir, say.... oops!
4D. So, those are the major ways one would normally get access to the cmdln, which is hidden underneath the pretty facade. There are some less-well-known ways: when booting, hold down shift to get to GRUB, and there is an option to drop to a GRUB shell (this is far more crippled than a normal ubuntu terminal session however). You can also, from that same GRUB menu, pick the recovery option, and tell it you want to drop to a root shell, in which case you will be logged into the kernel as the sole VT, with no ctrl+alt+F7 at all. Of course, if you can boot the system from usb or dvdrw or pxe or similar, you can get access to a cmdln from those OSes (and browse the internal drives assuming they are not encrypted). You can even go *really* old-school, and hook up an rs232 console during boot ... or be a bit wimpier and hook up a usb equivalent thereof. Rarely, usually only on high end servers, there is sometimes an IPMI-style chip on the motherboard, which allows you to get a limited form of xterm access to the PC, even when the rest of the system is nominally powered down; cool!
4E. Combinations are always a possibility: you can be logged into your machine, simultaneously, with ctrl+alt+t running, with xterm in another window, logged into VT#4, also logged into VT#5, ssh'd in from a nearby Win7 box, ssh'd in from a nearby OSX box, ssh'd in from a nearby Android tablet, running a serial console link, *and* sending IPMI packets.
So, we've gone pretty far afield, time to bring us back to the subject at hand. As the titlebar says, this security hole only impacts you if you are running Xmir now (prior to an official release of an ubuntu distro containing it which is going to be 13.10 unless a catastrophe happens), and if you also sometimes use VTs aka Ctrl+Alt+F4 and friends.
The request for testing -- note the stuff at the bottom talking about bug #1192843 and passwords -- but methinks there was a typo and the bugnum and the description are not actually on the appropriate lines -- https://lists.ubuntu.com/archives/ubuntu-devel/2013-August/037572.html
The updated instructions, now with the security problem right at the top, just as it should be -- https://wiki.ubuntu.com/Mir/Installing
On the other hand, the *wiki* instructions don't mention the security hole at all -- http://unity.ubuntu.com/mir/installing_prebuilt_on_pc.html
The bug itself -- was marked as fixed briefly, but was reopened by RAOF (one of the key Mir developers) as of 2013-09-02 for the unity compositor -- https://bugs.launchpad.net/xmir/+bug/1192843
So, to wrap up, although I may not be a "member of the community" that is involved in developing and testing Mir at the moment, I'm definitely involved in the community that is interested in preserving and promoting freedom. Part of that means being responsible when you release: if you have a known security hole, you fix it before you release, or you MAKE SURE ANYBODY INSTALLING your software knows about it. Using allcaps, if necessary. :-)
Canonical is interested in getting Mir into the wild, so they can have it be as fully tested as possible. (This is known as the new-jersey-slash-worse-is-better philosophy, in contrast with west-coast-slash-the-right-thing philosophy wayland is using. Google these terms if you don't think they are fair; C and UNIX are key examples of the former approach.) The approach is fine, release early and release often is a good methodology. But there is a difference between releasing something that is only partially finished, with known bugs, and missing features... versus releasing something with a known security hole, that could end up giving your testers a security compromise. One improves community, the other detracts from it. Anyhoo, in the sense of community, if this humongous post has not cleared things up for you, ask away. As long as mjg does not mind, I'll try and answer what you want to find out.
Power management, mobile and firmware developer on Linux. Security developer at Aurora. Ex-biologist. mjg59 on Twitter. Content here should not be interpreted as the opinion of my employer. Also on Mastodon.
![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
Re: only users running Xmir *and* using VTs *and* chat apps are impacted
Date: 2013-09-03 01:49 am (UTC)1. The person answering you, here and also above, is not the same as the person (mjg) who writes this blog. I'm just another reader, like you.
2A. Part of the reason that I felt the urge to be facetious was because your posting included some embedded assumptions. There is no frustration on my part with the 'community mgmt' side of this bug, because a) the bug is not in my code, and b) the community is not my own, in the sense you imply -- I neither develop Mir, nor use it, as yet (ditto for wayland as yet). I can assume much the same of mjg, though perhaps it is better to let him speak for himself: he does not work on mir, nor for canonical... he used to work for redhat, and nowadays mostly reverse-engineers proprietary bios stuff, from what I can tell. We are both interested in the Mir project, and in how canonical will handle it in the future, because we both care about the future of Linux.
2B. However, the *main* reason that I was somewhat facetious in my answer is because I thought your question was too incomplete to answer properly (which I suppose is unworthy of me in some realm of politeness... but if I do not express frustration then how would you realize there was even a problem, albeit a minor one, in the first place?) You did not specify what you meant by "typical user". You did not specify what you meant by "does some work". You did not specify any details about your concerns, that would allow me to give you a correct and non-facetious answer. See also, ESR's guide to smart questions. So, I gave you a somewhat facetious answer, starting with the statistically typical user, who is running win8, and cursing their luck.
3. Your longer explanation of your personal situation gives me enough clues to answer your real question: will this bug in Mir impact *you* given the way you work? No, you are safe. Even if you are running the pre-13.10 distro of some sort, with Mir and Xmir installed from universe, as the title of the mjg blogpost clearly says, this security problem only impacts people that use VTs, aka Ctrl+Alt+Fwhatever, *and* have chat-sessions running foreground in their Xmir session. You run chat sessions, you have Xmir (or perhaps are still thinking about testing it), but you don't use VTs.
4A. For your own edification, and anybody else reading the comments later, I'll give the concise overview of How Many Ways Can I Get To The Command Line Under Ubuntu, subject to limitations on my own knowledge. Nowadays, when you boot a desktop Linux distro, you immediately start working in Unity under X -- in other words, the GUI. There is a shortcut, which I believe is ubuntu-specific, where you hit Ctrl+Alt+t which opens up a window, inside which you see a command line prompt, where you can type command lines stuff, like grep and ls and all the other traditional Unix-like commands from the 1970s. This is not the only way to open such a thing: you can also hit the winkey, type xterm, and hit enter. More or less the same thing happens, although the details under the hood differ slightly (and the background color may differ as a visual indicator of what is happening). Normally, those are the only ways that the typical ubuntu enduser will interact with a cmdln.
4B. Of course, that's not the only way to get cmdln access. Assuming your machine has an sshd server running, an a known IP address (or even a domain name), you can usually walk away from your desktop, open up an ssh client on some other machine (ssh on Linux or PuTTY on windows or whatnot), and connect back to your desktop securely. You don't see the GUI portion of your desktop Ubuntu this way, unless you are doing ssh tunneling of a VNC connection or somesuch, but you do get cmdln access. Remotely! Nice.
4C. Walking back to your ubuntu PC again, and hit Ctrl+Alt+F4, and something Completely Different will happen. Your screen will change from 1080p mode down to something like an 80x25 vt100-style display-mode, and you will have stark white text (in an ugly font) on a stark black background. Welcome back to 1969: this is more or less how Kernighan and Richie logged into their original UNIX boxen. These are the VTs that were mentioned. By default, they are loaded when the kernel boots, and most endusers never need them, or indeed are even aware they are there. We used F4, so we're in VT#4. You can also switch over to VT5, which is a different login-session (logged out by default just like VT4 was). Your beautiful Unity & X stuff is not gone, by the way -- just hit Ctrl+Alt+F7 to return to the GUI session. You can think of the VTs as a primitive sort of "tabbed" xterms, more or less. They are mostly used as a last-resort fallback, when the X session is hung, and you need to get into the cmdln to restart everything, or something like that. Handy, if you are debugging a problem in Xmir, say.... oops!
4D. So, those are the major ways one would normally get access to the cmdln, which is hidden underneath the pretty facade. There are some less-well-known ways: when booting, hold down shift to get to GRUB, and there is an option to drop to a GRUB shell (this is far more crippled than a normal ubuntu terminal session however). You can also, from that same GRUB menu, pick the recovery option, and tell it you want to drop to a root shell, in which case you will be logged into the kernel as the sole VT, with no ctrl+alt+F7 at all. Of course, if you can boot the system from usb or dvdrw or pxe or similar, you can get access to a cmdln from those OSes (and browse the internal drives assuming they are not encrypted). You can even go *really* old-school, and hook up an rs232 console during boot ... or be a bit wimpier and hook up a usb equivalent thereof. Rarely, usually only on high end servers, there is sometimes an IPMI-style chip on the motherboard, which allows you to get a limited form of xterm access to the PC, even when the rest of the system is nominally powered down; cool!
4E. Combinations are always a possibility: you can be logged into your machine, simultaneously, with ctrl+alt+t running, with xterm in another window, logged into VT#4, also logged into VT#5, ssh'd in from a nearby Win7 box, ssh'd in from a nearby OSX box, ssh'd in from a nearby Android tablet, running a serial console link, *and* sending IPMI packets.
So, we've gone pretty far afield, time to bring us back to the subject at hand. As the titlebar says, this security hole only impacts you if you are running Xmir now (prior to an official release of an ubuntu distro containing it which is going to be 13.10 unless a catastrophe happens), and if you also sometimes use VTs aka Ctrl+Alt+F4 and friends.
The request for testing -- note the stuff at the bottom talking about bug #1192843 and passwords -- but methinks there was a typo and the bugnum and the description are not actually on the appropriate lines -- https://lists.ubuntu.com/archives/ubuntu-devel/2013-August/037572.html
The updated instructions, now with the security problem right at the top, just as it should be -- https://wiki.ubuntu.com/Mir/Installing
On the other hand, the *wiki* instructions don't mention the security hole at all -- http://unity.ubuntu.com/mir/installing_prebuilt_on_pc.html
The bug itself -- was marked as fixed briefly, but was reopened by RAOF (one of the key Mir developers) as of 2013-09-02 for the unity compositor -- https://bugs.launchpad.net/xmir/+bug/1192843
So, to wrap up, although I may not be a "member of the community" that is involved in developing and testing Mir at the moment, I'm definitely involved in the community that is interested in preserving and promoting freedom. Part of that means being responsible when you release: if you have a known security hole, you fix it before you release, or you MAKE SURE ANYBODY INSTALLING your software knows about it. Using allcaps, if necessary. :-)
Canonical is interested in getting Mir into the wild, so they can have it be as fully tested as possible. (This is known as the new-jersey-slash-worse-is-better philosophy, in contrast with west-coast-slash-the-right-thing philosophy wayland is using. Google these terms if you don't think they are fair; C and UNIX are key examples of the former approach.) The approach is fine, release early and release often is a good methodology. But there is a difference between releasing something that is only partially finished, with known bugs, and missing features... versus releasing something with a known security hole, that could end up giving your testers a security compromise. One improves community, the other detracts from it. Anyhoo, in the sense of community, if this humongous post has not cleared things up for you, ask away. As long as mjg does not mind, I'll try and answer what you want to find out.