Re: [arch-general] To those that are testing Gnome 3.14
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 09/26/2014 07:43 PM, Lorenzo Bandieri wrote: > Hi list, > > I have a favor to ask to those that are currently testing Gnome > 3.14. > > In gnome 3.12 I am having problems with user switching, which is > quite important for me. In particular, I had this annoying bug [1] > since I installed Gnome in this computer. When Xorg 1.16 came out, > it broke completely the switch user functionality for me (it caused > my system to hang, forcing me to send a SIGTERM with Alt+SysRq+e). > For what it's worth, I created a /etc/X11/Xwrapper.config, but that > did not solve the issue. At the time I didn't want to investigate > the issue since I needed the system to Just Work(tm), and I simply > downgraded Xorg. I'm still running with the old Xorg, but I know > that I can't go on like this forever. > > If anyone running Gnome 3.14 happened to test the switch user > functionality, I would be interested to know: - if you are > observing any problem switching user with Xorg 1.16, - if you are > observing Bug #730360; to test, see [1] > > Thanks in advance! > > Lorenzo > > > [1] https://bugzilla.gnome.org/show_bug.cgi?id=730360#c7 > Yes, it seems to still be broken in 3.14. I have had no issues without switching, but now that I tried it: - - The first time I "switched users" to myself, GNOME froze in the activities when I tried to open a terminal (because I had forgotten to give the new test user a password). I switched to a virtual console and did a reboot. - - The second time I clicked the "Switch User" button I wanted to check how many virtual terminals were open. It froze completely (except for standby nothing worked) when I switched terminals, although maybe that's because of the Intel driver. I did a non-clean poweroff. - - The third time I actually switched users. I could not switch back anymore from the log-in screen of the test user. When I tried the log-in-as-different-user button the screen was only gray with a pointer. I had to manually Ctrl+Alt+F2, which gave me the test user's log-in screen again. After repeating this for a while it froze and I rebooted. journalctl shows gdm-password repeatedly complaining that Sep 27 08:32:39 floriannotebook gdm-password][1433]: pam_unix(gdm-password:auth): conversation failed Sep 27 08:32:39 floriannotebook gdm-password][1433]: pam_unix(gdm-password:auth): auth could not identify password for [archie] Sep 27 08:32:39 floriannotebook gdm-password][1433]: gkr-pam: no password is available for user even though archie has a password; I also could log-in as archie. I did not see anything with shadow opacity in the journal though. So I think what you mean is still broken. -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBAgAGBQJUJl9SAAoJEMqreLELZNG3PHcP/jkzWN8NhbgWyZV4U8lQ875b pU/t/6tOE24CxVlG7CRYoO0Jtaj5UzYzWmIFSlU4MjcYrbiiT08jbYxwAF4R44DE H2JgEa8852RFEGTf/jDdk4mhDvZOyjowRyz88/7BZv2qoEdTjGiOGWPQMvepbter vYLINbNHGzyjO9i38JaMssqmnZJyt6+QV/RKV3isAGak6Iu5Cl9jOnpj/3Rmfgzs 7M+TOCHYL/VCPWdknKm5txlhvJ5wj0BMd1pqmBmlpDcw3Do1/wzXm75obJERoCPk cbhyW/EzYd9MqAy9oKHD5NjrQ+duhNeauxo0R4D7tRMS4/YHiKPaaealHu07vpH3 +svHHa03w1twICxh1IElci8JzSYzrUQF0OFnt9/aF3U6Nvm61KX/hdGeOc1ufkOF nOprEQGoTSPVrlQIQ639rX5VPJkfeo2xsJyZ/mIihrd4+5bkXt0FjHU3RPZoDTjA KURFOMwlIwFFoEG/Btp0XF21DDsfsBF9S479cytu0sFSCixY+YN/COkgH5MIIg+5 8+O55l6UOwHXrPc2rRGlc52FRHcXwRRy/Oj6OvbH9D6xcBbb7fr5Lbl4pY1xzioL OzfaW0bY+6Dbm3RFqQFHr8oey0R6CCVopB7448iSmCPOZiJ04oe5bklb5RR3ILVl a16i0ALEvW+4FJX84x63 =4ndI -END PGP SIGNATURE-
Re: [arch-general] A good time to switch to dash as /bin/sh?
On 2014-09-26 15:57, Doug Newgard wrote: On 2014-09-26 15:00, Benjamin A. Shelton wrote: On 09/26/2014 10:59 AM, Doug Newgard wrote: What technical reasons are there against switching out /bin/sh? Thusfar, I haven't encountered anything particularly noisome (the ST2's subl launch script being one exception, probably several others), but there's certainly something lurking in unseen dark corners. It seems (superficially, at least) that most everything else is well behaved and asks specifically for /bin/bash where expected. Should those circumstances where this isn't the case be considered bugs? I would say "yes," but others might emphatically say "no." Benjamin [1] http://pubs.opengroup.org/onlinepubs/009604599/basedefs/xbd_chap08.html [2] http://en.wikipedia.org/wiki/Almquist_shell My technical reason is simple, I don't think the base install should have to include another shell implementation when one is already available. If you want to switch /bin/sh on your machine, go for it. I just don't think having it as the default is a good way to go. I should qualify that in that I don't think adding another package to base is a good idea *unless* there is a significant benefit to doing so. The plan to add dash to base when Arch was using initscripts made sense, it doesn't now that we're using systemd. There's already too much in base IMO. Doug
Re: [arch-general] A good time to switch to dash as /bin/sh?
Hi, On Fri, Sep 26, 2014 at 03:57:54PM -0500, Doug Newgard wrote: > Yes, it's this paranoia that I've been trying to cut through in this thread > to get people to start discussing things rationally. Just an FYI for people running their own DHCP servers: http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2014q3/008859.html . That said, an up-to-date Arch install should be relatively safe. Cheers, -- Leonid Isaev GPG fingerprints: DA92 034D B4A8 EC51 7EA6 20DF 9291 EE8A 043C B8C4 C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D pgpk5dm8JiL_k.pgp Description: PGP signature
Re: [arch-general] A good time to switch to dash as /bin/sh?
On 2014-09-26 15:00, Benjamin A. Shelton wrote: On 09/26/2014 10:59 AM, Doug Newgard wrote: OK, we're finally getting some examples of where the sh symlink could be used to trigger this exploit. Thank you. There are samples that have been available for the past 2-3 days, and there's a fairly steady stream of new information on various sites (HN, probably Slashdot, among others). It isn't difficult to find, if you're willing to look, but you do have to sort through the cruft and the "sky is falling" paranoia. Yes, it's this paranoia that I've been trying to cut through in this thread to get people to start discussing things rationally. @Benjamin A. Shelton: What do you mean you'd support it for correctness? Bash is POSIX compliant, anything that uses only POSIX sh should run correctly on Bash. If it doens't, it should be reported upstream. I should specify that by correctness (in this case), I mean to say POSIX-compliant *minus* the bashisms and rather "interesting" behavior of the bash interpreter, in the sense that I can take a script written for /bin/sh and plop it down on any system that expects /bin/sh, and it doesn't perform (or provide) any additional magic. "Simpler" might also be an appropriate synonym. bash has some very convenient behaviors, but I'm not *completely* convinced that the additional features of a user shell should necessarily be exposed to applications that expect /bin/sh to behave consistently across Unix/Unix-like OSes (e.g. Apache's APR and others) while providing a rather creative interpretation of envvars. bash is big. I submit that the bug in question is *exactly* the sort of behavior in question and has, in fact, already been sent upstream (that's what these bug reports are for, correct?). I may be mistaken, but I don't believe interpreting a special string of characters in envvars as functions--even when invoked as /bin/sh--is considered POSIX behavior? Does POSIX even address this? I don't see anything that specifies such, and I'm inclined to believe it is bash specific [1] (please point out if I'm mistaken). POSIX generally says "it must do this", not "it can only do this and nothing more". As long as you can take any POSIX compliant sh script and run it on bash, it's compliant. You're wanting it to hide functionality in certain circumstances, which isn't wrong, but it isn't required. One way is not more correct than the other. Now my question for everyone else is, what will people do *WHEN* a bug is found in dash? Bash is the most tested shell code base we have, and I don't buy into the fallacy that a smaller code base is inherently more secure. Or are you simply relying on security through obscurity? I believe this "shellshock" vulnerability was discovered by a Red Hat auditor and has been exploitable for about one major version back. "Most tested" doesn't always mean "more secure." Also, dash is at least as old as bash [2]. Smaller code bases do in fact have the potential to be more secure simply by fault of their relative magnitude: Less code makes it more readily auditable in less time, and less code (all other things being equal) with fewer features will exhibit fewer bugs. It's a matter of probability. It's not an absolute, of course: Some software may be written by more skilled individuals, but as a code base grows to include more features, the probability that it will contain errors in its implementation approaches one. Smaller code bases can have the potential to be more secure, but that doesn't mean that they are. The shear amount of testing Bash gets run through being the default shell for so many things would suggest that it's likely more secure than a code base that doesn't get this testing. Similarly, I don't see how switching /bin/sh is security through obscurity; if someone were advocating replacing /bin/sh with (t)csh then yes, I might agree with that assertion, but replacing it with another sh implementation is not. There are only so many sh-compatible implementations available (and only so many licensed in a manner that GPL-licensed projects find palatable), so the limited selection most certainly is not compatible with such a charge. Let's look at security through obscurity. When Apple started making their comeback, one of the big reasons non-technical people gave over and over for switching is that OSX didn't have any viruses. As it became more popular, guess what happened? Simply put, the smaller the install base, the less motivation there is to break it. Dash has a far smaller install/user base than Bash, so Bash is a much larger target. What technical reasons are there against switching out /bin/sh? Thusfar, I haven't encountered anything particularly noisome (the ST2's subl launch script being one exception, probably several others), but there's certainly something lurking in unseen dark corners. It seems (superficially, at least) that most everything else is well behaved and asks specifically f
Re: [arch-general] A good time to switch to dash as /bin/sh?
On Sat, Sep 27, 2014, at 01:30 AM, Benjamin A. Shelton wrote: > On 09/26/2014 10:59 AM, Doug Newgard wrote: > > > > OK, we're finally getting some examples of where the sh symlink could > be used to trigger this exploit. Thank you. > > There are samples that have been available for the past 2-3 days, and > there's a fairly steady stream of new information on various sites (HN, > probably Slashdot, among others). It isn't difficult to find, if you're > willing to look, but you do have to sort through the cruft and the "sky > is falling" paranoia. > > > @Benjamin A. Shelton: What do you mean you'd support it for > correctness? Bash is POSIX compliant, anything that uses only POSIX sh > should run correctly on Bash. If it doens't, it should be reported > upstream. > > I should specify that by correctness (in this case), I mean to say > POSIX-compliant *minus* the bashisms and rather "interesting" behavior > of the bash interpreter, in the sense that I can take a script written > for /bin/sh and plop it down on any system that expects /bin/sh, and it > doesn't perform (or provide) any additional magic. "Simpler" might also > be an appropriate synonym. bash has some very convenient behaviors, but > I'm not *completely* convinced that the additional features of a user > shell should necessarily be exposed to applications that expect /bin/sh > to behave consistently across Unix/Unix-like OSes (e.g. Apache's APR and > others) while providing a rather creative interpretation of envvars. > bash is big. > > I submit that the bug in question is *exactly* the sort of behavior in > question and has, in fact, already been sent upstream (that's what these > bug reports are for, correct?). I may be mistaken, but I don't believe > interpreting a special string of characters in envvars as > functions--even when invoked as /bin/sh--is considered POSIX behavior? > Does POSIX even address this? I don't see anything that specifies such, > and I'm inclined to believe it is bash specific [1] (please point out if > I'm mistaken). > > > Now my question for everyone else is, what will people do *WHEN* a > bug is found in dash? Bash is the most tested shell code base we have, > and I don't buy into the fallacy that a smaller code base is inherently > more secure. Or are you simply relying on security through obscurity? > > I believe this "shellshock" vulnerability was discovered by a Red Hat > auditor and has been exploitable for about one major version back. "Most > tested" doesn't always mean "more secure." Also, dash is at least as old > as bash [2]. > > Smaller code bases do in fact have the potential to be more secure > simply by fault of their relative magnitude: Less code makes it more > readily auditable in less time, and less code (all other things being > equal) with fewer features will exhibit fewer bugs. It's a matter of > probability. It's not an absolute, of course: Some software may be > written by more skilled individuals, but as a code base grows to include > more features, the probability that it will contain errors in its > implementation approaches one. > > Similarly, I don't see how switching /bin/sh is security through > obscurity; if someone were advocating replacing /bin/sh with (t)csh then > yes, I might agree with that assertion, but replacing it with another sh > implementation is not. There are only so many sh-compatible > implementations available (and only so many licensed in a manner that > GPL-licensed projects find palatable), so the limited selection most > certainly is not compatible with such a charge. > > What technical reasons are there against switching out /bin/sh? Thusfar, > I haven't encountered anything particularly noisome (the ST2's subl > launch script being one exception, probably several others), but there's > certainly something lurking in unseen dark corners. It seems > (superficially, at least) that most everything else is well behaved and > asks specifically for /bin/bash where expected. Should those > circumstances where this isn't the case be considered bugs? I would say > "yes," but others might emphatically say "no." > > Benjamin > > [1] > http://pubs.opengroup.org/onlinepubs/009604599/basedefs/xbd_chap08.html > [2] http://en.wikipedia.org/wiki/Almquist_shell I guess the bug report I opened has a pretty damning reason: https://bugs.archlinux.org/task/42134#comment128011 Given by Dave with a source, so... If there's a reason it doesn't matter, be a dear and comment on the bug, will you? -- Cheers! Savya
Re: [arch-general] A good time to switch to dash as /bin/sh?
On 09/26/2014 10:59 AM, Doug Newgard wrote: > > OK, we're finally getting some examples of where the sh symlink could be used to trigger this exploit. Thank you. There are samples that have been available for the past 2-3 days, and there's a fairly steady stream of new information on various sites (HN, probably Slashdot, among others). It isn't difficult to find, if you're willing to look, but you do have to sort through the cruft and the "sky is falling" paranoia. > @Benjamin A. Shelton: What do you mean you'd support it for correctness? Bash is POSIX compliant, anything that uses only POSIX sh should run correctly on Bash. If it doens't, it should be reported upstream. I should specify that by correctness (in this case), I mean to say POSIX-compliant *minus* the bashisms and rather "interesting" behavior of the bash interpreter, in the sense that I can take a script written for /bin/sh and plop it down on any system that expects /bin/sh, and it doesn't perform (or provide) any additional magic. "Simpler" might also be an appropriate synonym. bash has some very convenient behaviors, but I'm not *completely* convinced that the additional features of a user shell should necessarily be exposed to applications that expect /bin/sh to behave consistently across Unix/Unix-like OSes (e.g. Apache's APR and others) while providing a rather creative interpretation of envvars. bash is big. I submit that the bug in question is *exactly* the sort of behavior in question and has, in fact, already been sent upstream (that's what these bug reports are for, correct?). I may be mistaken, but I don't believe interpreting a special string of characters in envvars as functions--even when invoked as /bin/sh--is considered POSIX behavior? Does POSIX even address this? I don't see anything that specifies such, and I'm inclined to believe it is bash specific [1] (please point out if I'm mistaken). > Now my question for everyone else is, what will people do *WHEN* a bug is found in dash? Bash is the most tested shell code base we have, and I don't buy into the fallacy that a smaller code base is inherently more secure. Or are you simply relying on security through obscurity? I believe this "shellshock" vulnerability was discovered by a Red Hat auditor and has been exploitable for about one major version back. "Most tested" doesn't always mean "more secure." Also, dash is at least as old as bash [2]. Smaller code bases do in fact have the potential to be more secure simply by fault of their relative magnitude: Less code makes it more readily auditable in less time, and less code (all other things being equal) with fewer features will exhibit fewer bugs. It's a matter of probability. It's not an absolute, of course: Some software may be written by more skilled individuals, but as a code base grows to include more features, the probability that it will contain errors in its implementation approaches one. Similarly, I don't see how switching /bin/sh is security through obscurity; if someone were advocating replacing /bin/sh with (t)csh then yes, I might agree with that assertion, but replacing it with another sh implementation is not. There are only so many sh-compatible implementations available (and only so many licensed in a manner that GPL-licensed projects find palatable), so the limited selection most certainly is not compatible with such a charge. What technical reasons are there against switching out /bin/sh? Thusfar, I haven't encountered anything particularly noisome (the ST2's subl launch script being one exception, probably several others), but there's certainly something lurking in unseen dark corners. It seems (superficially, at least) that most everything else is well behaved and asks specifically for /bin/bash where expected. Should those circumstances where this isn't the case be considered bugs? I would say "yes," but others might emphatically say "no." Benjamin [1] http://pubs.opengroup.org/onlinepubs/009604599/basedefs/xbd_chap08.html [2] http://en.wikipedia.org/wiki/Almquist_shell
Re: [arch-general] A good time to switch to dash as /bin/sh?
I've requested it as a feature. Hope it gets traction. https://bugs.archlinux.org/task/42134 -- Cheers! Savya
Re: [arch-general] A good time to switch to dash as /bin/sh?
The flaw is not patched correctly. Tavis Ormandy has shown it to be still exploitable. Chester On 26 September 2014 11:23:59 GMT-07:00, Guus Snijders wrote: >Op 26 sep. 2014 16:34 schreef "Doug Newgard" : >[...] >> >> Instead of theorizing that "many" will do this, give a real world >example >of where this happens and would have reduced the attack surface of the >bug >in question. > >One of the very few examples that sound reasonable, is dhclient. >Apparently, that can be readily used for this bug to be exploited. >Sounds >like more of problem with dhclient, though. > >I agree that there's a lot of fud out there about this bug; once found >(or >perhaps: cve assigned), the patches came quickly, so that actually >looks >quite good for bash! > >Switching /bin/sh to dash has been discussed before and we can spend a >lot >of e-mails on that, but as usual it's up to devs to implement it as >such, >or not. > >Just my E0, 02 > >Mvg, Guus
Re: [arch-general] A good time to switch to dash as /bin/sh?
Op 26 sep. 2014 16:34 schreef "Doug Newgard" : [...] > > Instead of theorizing that "many" will do this, give a real world example of where this happens and would have reduced the attack surface of the bug in question. One of the very few examples that sound reasonable, is dhclient. Apparently, that can be readily used for this bug to be exploited. Sounds like more of problem with dhclient, though. I agree that there's a lot of fud out there about this bug; once found (or perhaps: cve assigned), the patches came quickly, so that actually looks quite good for bash! Switching /bin/sh to dash has been discussed before and we can spend a lot of e-mails on that, but as usual it's up to devs to implement it as such, or not. Just my E0, 02 Mvg, Guus
[arch-general] To those that are testing Gnome 3.14
Hi list, I have a favor to ask to those that are currently testing Gnome 3.14. In gnome 3.12 I am having problems with user switching, which is quite important for me. In particular, I had this annoying bug [1] since I installed Gnome in this computer. When Xorg 1.16 came out, it broke completely the switch user functionality for me (it caused my system to hang, forcing me to send a SIGTERM with Alt+SysRq+e). For what it's worth, I created a /etc/X11/Xwrapper.config, but that did not solve the issue. At the time I didn't want to investigate the issue since I needed the system to Just Work(tm), and I simply downgraded Xorg. I'm still running with the old Xorg, but I know that I can't go on like this forever. If anyone running Gnome 3.14 happened to test the switch user functionality, I would be interested to know: - if you are observing any problem switching user with Xorg 1.16, - if you are observing Bug #730360; to test, see [1] Thanks in advance! Lorenzo [1] https://bugzilla.gnome.org/show_bug.cgi?id=730360#c7
Re: [arch-general] A good time to switch to dash as /bin/sh?
On Fri, Sep 26, 2014, at 10:29 PM, Doug Newgard wrote: > Now my question for everyone else is, what will people do *WHEN* a bug > is found in dash? Bash is the most tested shell code base we have, and I > don't buy into the fallacy that a smaller code base is inherently more > secure. Or are you simply relying on security through obscurity? > Email had 1 attachment: > + pubkey.asc > 1k (text/plain) Dash has Debian in its very name. It's the Debian Almquist Shell. Ubuntu also uses it. It might not be as tested as bash, but that doesn't mean it's very rare. I don't think this falls under security through obscurity. Ubuntu and Debian also shifted to it quite a long while back (it has been more than 5 years now). Dash comes from Ash (Almquist Shell), which is from the 90s. The codebase is hardly new. And as for what people will do, why, they will report it like always. Has Arch ever encouraged anything else? -- Cheers! Savya
Re: [arch-general] A good time to switch to dash as /bin/sh?
On 2014-09-26 11:46, Benjamin A. Shelton wrote: On 09/26/2014 10:16 AM, Leonid Isaev wrote: The bugs which started this discussion are not a big deal anyway. They will only affect scripts that don't properly sanitize the input. Such scripts have bigger problems to worry about IMHO. The SSH-related issue is also insignificant because the bug will be triggered post-auth... Cheers, The bug can be triggered by Apache and is potentially not limited to CGI alone [1] if /bin/sh links to bash. As others have stated earlier, certain syscalls can also serve as a vector, which implies that simply avoiding CGI (FastCGI, mod_*) may not provide complete resolution. I don't know if Arch is affected, but there's a proof of concept floating around (ab)using dhcpcd's hook scripts [2] to exploit clients on a potentially hostile network. It also appears possible that previous patches have *not* completely fixed the issue [3]. I'm just a user of Arch, and while I agree (to an extent) this issue may be overblown, I certainly don't think sticking our head in the sand, pretending it doesn't exist (or cannot affect us) is a viable long-term solution. That said, I agree with the others here: The primary reason I'd support linking /bin/sh to dash is to favor correctness. From such a standpoint, if a script asks for /bin/sh, it should expect a POSIX-compliant sh and should not rely on bashisms (i.e. I should be able to move it to *BSD or other platforms and it ought to simply work). Therefore, I agree that any improvement in terms of security would be relegated to a convenient side effect. [1] http://security.stackexchange.com/a/68164 [2] https://www.trustedsec.com/september-2014/shellshock-dhcp-rce-proof-concept/ [3] http://seclists.org/oss-sec/2014/q3/741 OK, we're finally getting some examples of where the sh symlink could be used to trigger this exploit. Thank you. @Benjamin A. Shelton: What do you mean you'd support it for correctness? Bash is POSIX compliant, anything that uses only POSIX sh should run correctly on Bash. If it doens't, it should be reported upstream. Now my question for everyone else is, what will people do *WHEN* a bug is found in dash? Bash is the most tested shell code base we have, and I don't buy into the fallacy that a smaller code base is inherently more secure. Or are you simply relying on security through obscurity?
Re: [arch-general] A good time to switch to dash as /bin/sh?
On 26/09/14 11:16, Leonid Isaev wrote: > $ head -n1 /usr/bin/mkinitcpio > #!/bin/bash > --- > > So, yes ArchLinux core tools use and will continue to use 'bashisms' because > they are convenient. Right, and I'm more or less fine with that _because_ of the above shebang line, and I'm also fine with bash being an essential package. When I say "bashism" I mean in the specific sense of "programs that assume that /bin/sh is bash and casually break otherwise because they haven't been tested with anything else", not "all bash scripting in general", nor even "programs that assume /bin/sh is bash because it's been established as policy by some other means". Assumptions that happen to hold in too many cases by accident become dangerous cognitive shortcuts, and letting them get entrenched without thinking about them leads to bizarre, inescapable compatibility situations getting worse and impeding any further development. I admit feeling a bit insulted having my mail quoted as a "witch hunt". The recent events were only a trigger to reëxamine something I'd considered doing ever since the first install a long while back. ---> Drake Wilson
Re: [arch-general] A good time to switch to dash as /bin/sh?
On 09/26/2014 10:16 AM, Leonid Isaev wrote: > The bugs which started this discussion are not a big deal anyway. They > will only affect scripts that don't properly sanitize the input. Such > scripts have bigger problems to worry about IMHO. The SSH-related > issue is also insignificant because the bug will be triggered > post-auth... Cheers, The bug can be triggered by Apache and is potentially not limited to CGI alone [1] if /bin/sh links to bash. As others have stated earlier, certain syscalls can also serve as a vector, which implies that simply avoiding CGI (FastCGI, mod_*) may not provide complete resolution. I don't know if Arch is affected, but there's a proof of concept floating around (ab)using dhcpcd's hook scripts [2] to exploit clients on a potentially hostile network. It also appears possible that previous patches have *not* completely fixed the issue [3]. I'm just a user of Arch, and while I agree (to an extent) this issue may be overblown, I certainly don't think sticking our head in the sand, pretending it doesn't exist (or cannot affect us) is a viable long-term solution. That said, I agree with the others here: The primary reason I'd support linking /bin/sh to dash is to favor correctness. From such a standpoint, if a script asks for /bin/sh, it should expect a POSIX-compliant sh and should not rely on bashisms (i.e. I should be able to move it to *BSD or other platforms and it ought to simply work). Therefore, I agree that any improvement in terms of security would be relegated to a convenient side effect. [1] http://security.stackexchange.com/a/68164 [2] https://www.trustedsec.com/september-2014/shellshock-dhcp-rce-proof-concept/ [3] http://seclists.org/oss-sec/2014/q3/741
Re: [arch-general] A good time to switch to dash as /bin/sh?
On Fri, 2014-09-26 at 13:27 -0300, Hugo Osvaldo Barrera wrote: > I strongly agree with this. Programs that ask for sh should get sh, and > programs that ask for bash should get bash. > > Programs that ask for bash and use bashisms are already broken for the Ubuntu > family (ie: Ubuntu and derivates), and on any *BSD, and *need to be fixed > upstream*! > > I also remember having to port some scripts from BSD to Arch and seeing how > they broke on bash because bash has non-sh behaviours. > > Bash is not sh, and should not be treated as such. I've no issue with having > bash in my system and that scripts with the proper shebang use it. Too funny, off-list I wrote somebody and mentioned: "[snip] I prefer dash over bash for compatibility reasons. My "main" distro is Arch Linux, but I watch what's happening with other distros (and FreeBSD). [snip] Btw. FreeBSD goes a completely different way ;) [snip]" I BCC the mail to this person ;).
Re: [arch-general] A good time to switch to dash as /bin/sh?
On 2014-09-26 11:27, Hugo Osvaldo Barrera wrote: On 2014-09-26 07:30, Drake Wilson wrote: On 26/09/14 07:06, Mailing Lists (???) wrote: > Even if we agree to shift /bin/sh to dash, I'm not sure that it'll make > that much of a difference. From what I've read, most of the problems > come from CGI scripts which invoke bash, and ssh post-authentication. Anything that uses system(), popen(), or other similar "invoke command (implicitly via /bin/sh)" functions can be affected by problems with whatever is installed as /bin/sh. Some daemon configurations have lines for hooks: "invoke shell command when occurs", with information passed to the command by various means (parameters, environment variables, etc.). Some programs allow specification of I/O targets as pipes to or from shell commands. There is a _lot_ of "magic behavior" in bash. Debian bug #762839 mentions how bash still imports shell functions from environment variables with magic names, even when called as sh. The --posix option seems something of a joke. dash has some of this as well (in particular, it interprets CDPATH) but not nearly as much, and it's much less likely to gain more in the future. I would support a move to dash as sh, but it's not primarily for security per se but for general cleanliness: bash as sh does more to encourage the proliferation of "presumptive bashisms" and has much more potential for future breakage in central system areas. I believe this is more in line with Arch's "Simplicity" and "Code-correctness over convenience" principles than conflating the needs of interactive and whole-system-default shells for convenience's sake, especially if bash is a moving target regarding which features might be enabled that might interfere with global functionality. I strongly agree with this. Programs that ask for sh should get sh, and programs that ask for bash should get bash. Programs that ask for bash and use bashisms are already broken for the Ubuntu family (ie: Ubuntu and derivates), and on any *BSD, and *need to be fixed upstream*! I also remember having to port some scripts from BSD to Arch and seeing how they broke on bash because bash has non-sh behaviours. Bash is not sh, and should not be treated as such. I've no issue with having bash in my system and that scripts with the proper shebang use it. If Bash's behavior doesn't comply with POSIX sh when called from the sh symlink, that's a bug and should be reported upstream. I would not support a move of the _packaging_ system to another sh, because that's explicitly documented to use bash as its main scripting language and relies on its extended features, and the potential complications are better contained. I don't think that's relevant unless the current packaging system assumes that bash can be invoked as sh. The case of interactive SSH is separate, because that depends on the user's interactive shell, not sh. The case of machine SSH in which the target account's shell is sh falls loosely into the program-program interoperation category. On my own desktop system, when I realized sh was bash recently I immediately relinked it to dash and intend to keep it that way as long as I reasonably can (I assume some things may break, in the current state; I'm willing to deal with that on my own for now). ---> Drake Wilson
Re: [arch-general] A good time to switch to dash as /bin/sh?
On 2014-09-26 07:30, Drake Wilson wrote: > On 26/09/14 07:06, Mailing Lists (???) wrote: > > Even if we agree to shift /bin/sh to dash, I'm not sure that it'll make > > that much of a difference. From what I've read, most of the problems > > come from CGI scripts which invoke bash, and ssh post-authentication. > > Anything that uses system(), popen(), or other similar "invoke command > (implicitly via /bin/sh)" functions can be affected by problems with > whatever is installed as /bin/sh. Some daemon configurations have lines > for hooks: "invoke shell command when occurs", with information > passed to the command by various means (parameters, environment variables, > etc.). Some programs allow specification of I/O targets as pipes to or > from shell commands. > > There is a _lot_ of "magic behavior" in bash. Debian bug #762839 mentions > how bash still imports shell functions from environment variables with magic > names, even when called as sh. The --posix option seems something of a joke. > > dash has some of this as well (in particular, it interprets CDPATH) but > not nearly as much, and it's much less likely to gain more in the future. > > I would support a move to dash as sh, but it's not primarily for security > per se but for general cleanliness: bash as sh does more to encourage the > proliferation of "presumptive bashisms" and has much more potential for > future breakage in central system areas. I believe this is more in line > with Arch's "Simplicity" and "Code-correctness over convenience" principles > than conflating the needs of interactive and whole-system-default shells for > convenience's sake, especially if bash is a moving target regarding which > features might be enabled that might interfere with global functionality. > I strongly agree with this. Programs that ask for sh should get sh, and programs that ask for bash should get bash. Programs that ask for bash and use bashisms are already broken for the Ubuntu family (ie: Ubuntu and derivates), and on any *BSD, and *need to be fixed upstream*! I also remember having to port some scripts from BSD to Arch and seeing how they broke on bash because bash has non-sh behaviours. Bash is not sh, and should not be treated as such. I've no issue with having bash in my system and that scripts with the proper shebang use it. > I would not support a move of the _packaging_ system to another sh, because > that's explicitly documented to use bash as its main scripting language and > relies on its extended features, and the potential complications are better > contained. I don't think that's relevant unless the current packaging system > assumes that bash can be invoked as sh. > > The case of interactive SSH is separate, because that depends on the user's > interactive shell, not sh. The case of machine SSH in which the target > account's shell is sh falls loosely into the program-program interoperation > category. > > On my own desktop system, when I realized sh was bash recently I immediately > relinked it to dash and intend to keep it that way as long as I reasonably > can (I assume some things may break, in the current state; I'm willing to > deal with that on my own for now). > >---> Drake Wilson -- Hugo Osvaldo Barrera A: Because we read from top to bottom, left to right. Q: Why should I start my reply below the quoted text? pgpSOq_cBNczf.pgp Description: PGP signature
Re: [arch-general] A good time to switch to dash as /bin/sh?
On 26 September 2014 18:16, Leonid Isaev wrote: > --- > > So, yes ArchLinux core tools use and will continue to use 'bashisms' > because > they are convenient. The bugs which started this discussion are not a big > deal > anyway. They will only affect scripts that don't properly sanitize the > input. > Such scripts have bigger problems to worry about IMHO. The SSH-related > issue is > also insignificant because the bug will be triggered post-auth... > > I very much disagree with that statement. Any ssh key with an attached force-command could be used to execute arbitrary commands. Then there is dhclient which passes information to scripts in environment variables, meaning that dhcp servers (for example on a public network) could execute commands on vulnerable clients. I would say both are a big deal and they are just two examples. But as said by others, the recent bash vulnerability has been fixed and that was not the point of this discussion anyway.
Re: [arch-general] Mailinglist migration test
On 2014-09-26 18:08, Florian Pritz wrote: > This mail should now come with the correct List-Id header and should > work with old filters. Sorry for the noise earlier. > The X-BeenThere header seems to have changed, but I'm now relying on List-Id anyway (which is actually standard). Other that relied on X-BeenThere may have noticed their filters broken too. -- Hugo Osvaldo Barrera A: Because we read from top to bottom, left to right. Q: Why should I start my reply below the quoted text? pgpU0WGuGnEkr.pgp Description: PGP signature
Re: [arch-general] A good time to switch to dash as /bin/sh?
Hi, On Fri, Sep 26, 2014 at 07:30:29AM -0500, Drake Wilson wrote: > [...] > On my own desktop system, when I realized sh was bash recently I immediately > relinked it to dash and intend to keep it that way as long as I reasonably > can (I assume some things may break, in the current state; I'm willing to > deal with that on my own for now). Guys, please stop this witch hunt. If you don't trust bash, then get rid of it, but don't forget that: --- $ head -n1 /usr/bin/mkinitcpio #!/bin/bash --- So, yes ArchLinux core tools use and will continue to use 'bashisms' because they are convenient. The bugs which started this discussion are not a big deal anyway. They will only affect scripts that don't properly sanitize the input. Such scripts have bigger problems to worry about IMHO. The SSH-related issue is also insignificant because the bug will be triggered post-auth... Cheers, -- Leonid Isaev GPG fingerprints: DA92 034D B4A8 EC51 7EA6 20DF 9291 EE8A 043C B8C4 C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D pgpEm_qlnUdLv.pgp Description: PGP signature
[arch-general] Mailinglist migration test
This mail should now come with the correct List-Id header and should work with old filters. Sorry for the noise earlier. signature.asc Description: OpenPGP digital signature
Re: [arch-general] A good time to switch to dash as /bin/sh?
On Fri, Sep 26, 2014, at 08:10 PM, Maarten de Vries wrote: > So you do not find "any program that calls system()" specific and scary > enough? I do. I guess specific examples really would help making a good case, you know? Being a non-programmer/sysad here, I'd be able to better support you if you gave me some specific names. Second, wouldn't it be better to open an issue on Flyspray for this? You'd be able to convince the concerned dev directly there. -- Cheers! Savya
Re: [arch-general] A good time to switch to dash as /bin/sh?
On 2014-09-26 09:29, Maarten de Vries wrote:
On 26 September 2014 16:25, Doug Newgard
wrote:
On 2014-09-26 09:15, lolilolicon wrote:
On Fri, Sep 26, 2014 at 9:50 PM, Doug Newgard
wrote:
The problem is on many systems /bin/sh is linked to bash -- which is
why
this bug is so widespread / severe. /bin/sh is "the single biggest
UNIX loophole", so let's make it a bit smaller by switching it to
something minimal, such as dash.
Why? Why is that the problem? What attack vector is available
because of
this? Give me specifics, not theoretical, non-existent examples.
Because the vulnerable systems do not call bash by name, they call
/bin/sh. And they are vulnerable only because /bin/sh is linked to
bash.
Wrong, they DO call bash by name. The main issues are with ssh, which
uses
the user's specified interactive shell, and with Apache's mod_cgi and
mod_cgid, which do call bash. Again, stop providing non-existent FUD
and
give real-world examples of where having /bin/sh linked to something
else
would have mitigated this.
Some programs may call bash by name, but many will just use system()
and
get bash without asking for it.
From man 3 system:
The system() library function uses fork(2) to create a child process
that
executes the shell command specified in command using execl(3) as
follows: execl("/bin/sh", "sh", "-c", command, (char *) 0);
Instead of theorizing that "many" will do this, give a real world
example of where this happens and would have reduced the attack surface
of the bug in question.
Re: [arch-general] A good time to switch to dash as /bin/sh?
On 26 September 2014 16:25, Doug Newgard wrote:
> On 2014-09-26 09:15, lolilolicon wrote:
>
>> On Fri, Sep 26, 2014 at 9:50 PM, Doug Newgard
>> wrote:
>>
>>> The problem is on many systems /bin/sh is linked to bash -- which is why
this bug is so widespread / severe. /bin/sh is "the single biggest
UNIX loophole", so let's make it a bit smaller by switching it to
something minimal, such as dash.
>>>
>>>
>>> Why? Why is that the problem? What attack vector is available because of
>>> this? Give me specifics, not theoretical, non-existent examples.
>>>
>>
>> Because the vulnerable systems do not call bash by name, they call
>> /bin/sh. And they are vulnerable only because /bin/sh is linked to bash.
>>
>
> Wrong, they DO call bash by name. The main issues are with ssh, which uses
> the user's specified interactive shell, and with Apache's mod_cgi and
> mod_cgid, which do call bash. Again, stop providing non-existent FUD and
> give real-world examples of where having /bin/sh linked to something else
> would have mitigated this.
Some programs may call bash by name, but many will just use system() and
get bash without asking for it.
>From man 3 system:
The system() library function uses fork(2) to create a child process that
> executes the shell command specified in command using execl(3) as
> follows: execl("/bin/sh", "sh", "-c", command, (char *) 0);
>
Re: [arch-general] A good time to switch to dash as /bin/sh?
On 2014-09-26 09:15, lolilolicon wrote:
On Fri, Sep 26, 2014 at 9:50 PM, Doug Newgard
wrote:
The problem is on many systems /bin/sh is linked to bash -- which is
why
this bug is so widespread / severe. /bin/sh is "the single biggest
UNIX loophole", so let's make it a bit smaller by switching it to
something minimal, such as dash.
Why? Why is that the problem? What attack vector is available because
of
this? Give me specifics, not theoretical, non-existent examples.
Because the vulnerable systems do not call bash by name, they call
/bin/sh. And they are vulnerable only because /bin/sh is linked to
bash.
Wrong, they DO call bash by name. The main issues are with ssh, which
uses the user's specified interactive shell, and with Apache's mod_cgi
and mod_cgid, which do call bash. Again, stop providing non-existent FUD
and give real-world examples of where having /bin/sh linked to something
else would have mitigated this.
Specifically, only on systems where /bin/sh is bash, any ENV whose
value
starts with '() {' gets turned into a function by the shell.
(It's being patched up, but this whole affair is telling...)
This is pretty real, unless what you want is some vivid horror story.
Re: [arch-general] A good time to switch to dash as /bin/sh?
On Fri, Sep 26, 2014 at 9:50 PM, Doug Newgard wrote:
>> The problem is on many systems /bin/sh is linked to bash -- which is why
>> this bug is so widespread / severe. /bin/sh is "the single biggest
>> UNIX loophole", so let's make it a bit smaller by switching it to
>> something minimal, such as dash.
>
>
> Why? Why is that the problem? What attack vector is available because of
> this? Give me specifics, not theoretical, non-existent examples.
Because the vulnerable systems do not call bash by name, they call
/bin/sh. And they are vulnerable only because /bin/sh is linked to bash.
Specifically, only on systems where /bin/sh is bash, any ENV whose value
starts with '() {' gets turned into a function by the shell.
(It's being patched up, but this whole affair is telling...)
This is pretty real, unless what you want is some vivid horror story.
Re: [arch-general] multiarch support like debian, pro and cons?
It is only my experience as normal user. It was not that easy to compile Wine 64 on a Debian multiarch system because of the package dependencies between 32 and 64 bit. The only solution to compile the 32 bit part for Wine on a Debian multiarch system was to create a 32 bit schroot jail. For me as user it was more like using 2 systems to compile one an the same package. Maybe they have fixed stuff in 7.6 but for me it was one of the reasons to install Archlinux.
Re: [arch-general] A good time to switch to dash as /bin/sh?
On 2014-09-26 07:29, lolilolicon wrote: On Fri, Sep 26, 2014 at 8:13 PM, Martti Kühne wrote: On Fri, Sep 26, 2014 at 2:06 PM, Mailing Lists wrote: Even if we agree to shift /bin/sh to dash, I'm not sure that it'll make that much of a difference. From what I've read, most of the problems come from CGI scripts which invoke bash, and ssh post-authentication. I'm not saying that these are the only vectors of attack, no, but these are the ones which are mentioned the most. Since bash is not generally used remotely (except in the case of sshing to a remote machine), I The problem is on many systems /bin/sh is linked to bash -- which is why this bug is so widespread / severe. /bin/sh is "the single biggest UNIX loophole", so let's make it a bit smaller by switching it to something minimal, such as dash. Why? Why is that the problem? What attack vector is available because of this? Give me specifics, not theoretical, non-existent examples. doubt that removing bashisms from most such scripts will really make much difference in security. How many of these scripts are even called remotely? How many of them actually form an attack surface? Do you have any data for that? Without actually having this data, it seems irresponsible to talk about shifting. Removing bashisms would not have any inpact in security but rather enable us switching /bin/sh away from /usr/bin/bash. Which we in general appear to agree on? Indeed. We're not talking about this specific bash bug here. We're not even talking about security specifically, although it would be an important side effect.
Re: [arch-general] A good time to switch to dash as /bin/sh?
On Fri, Sep 26, 2014, at 05:43 PM, Martti Kühne wrote: > Removing bashisms would not have any inpact in security but rather > enable us switching /bin/sh away from /usr/bin/bash. Which we in > general appear to agree on? > > cheers! > mar77i We do, but let's hope a dev weighs in on this. Or rather, it's time to open a bug report. -- Cheers! Savya
[arch-general] Gnome 3.14 boot hanging (Reached System Update Target)
Hi, I just upgraded to Gnome 3.14 and wanted to test new things, especially the new Pacman backend to PackageKit (through gnome-software). I just clicked on the "update and restart" notification and I couldn't boot anymore. I remove the "quiet" kernel boot flag in Grub and saw that the offending line was "[OK] Reached System Update Target". There was no timeout so my system just hanged like that for a dozen of minutes (coffee time). No TTY was available. I solved this by adding the "single" kernel boot flag in Grub, then log in as root, then remove the /system-update folder then reboot. Regards
Re: [arch-general] A good time to switch to dash as /bin/sh?
On Fri, Sep 26, 2014 at 8:40 PM, Drake Wilson wrote: > Aside: I'm not sure about the interpretation of checkbashisms re autotools > scripts (in particular libtool) because they do an awful lot of weird code > generation and shuffling to deal with multiple bogus shell implementations. Yes, you'd expect that they knew better. I haven't looked into it thoroughly, but libtool does seem to require bash -- but it may depend on the build process.
Re: [arch-general] A good time to switch to dash as /bin/sh?
On 26/09/14 07:30, Drake Wilson wrote:
> There is a _lot_ of "magic behavior" in bash. Debian bug #762839 mentions
> how bash still imports shell functions from environment variables with magic
> names, even when called as sh. The --posix option seems something of a joke.
Sorry, I mistyped; I meant magic values.
Incidentally this means that any environment variable of that form that
passes _through_ a bash instance to a subprocess will silently get mangled
in transit:
% env 'foo=() { true; true; }' bash -c "dash -c 'printf %sn \"\$foo\"'"
() { true;
true
}
The function definition was reconstructed from some internal form
and reinjected into the environment, as you can see. And of course during
the bash script itself it's not interpreted as a variable:
% env 'foo=() { true; true; }' bash -c "printf '%s\\n' \"\${foo-oops}\""
oops
How much more of this "hidden treasure" is there?
(There might be another approach involving convincing bash upstream to be
much stricter in --posix mode or when invoked as sh or something, but that
seems like a lot more work and less reliable.)
Aside: I'm not sure about the interpretation of checkbashisms re autotools
scripts (in particular libtool) because they do an awful lot of weird code
generation and shuffling to deal with multiple bogus shell implementations.
---> Drake Wilson
Re: [arch-general] A good time to switch to dash as /bin/sh?
On Fri, Sep 26, 2014 at 8:19 PM, Mailing Lists wrote: > On Fri, Sep 26, 2014, at 05:43 PM, Martti Kühne wrote: >> Removing bashisms would not have any inpact in security but rather >> enable us switching /bin/sh away from /usr/bin/bash. Which we in >> general appear to agree on? >> >> cheers! >> mar77i > > No problems there. All I'm saying is that switching should be done if > the effort is worth it in terms of increased security, and if getting > rid of bashisms isn't that huge a problem. Otherwise who am I to > question a performance boost? I'm not after a performance boost either, although again, it would be a nice side effect. Getting rid of bashism isn't hard: upon further inspection, I find there are extremely few #!/bin/sh scripts that will not work with dash. Perhaps debian has worked with upstream to improve the situation? I don't know.
Re: [arch-general] A good time to switch to dash as /bin/sh?
On 26/09/14 07:06, Mailing Lists (???) wrote: > Even if we agree to shift /bin/sh to dash, I'm not sure that it'll make > that much of a difference. From what I've read, most of the problems > come from CGI scripts which invoke bash, and ssh post-authentication. Anything that uses system(), popen(), or other similar "invoke command (implicitly via /bin/sh)" functions can be affected by problems with whatever is installed as /bin/sh. Some daemon configurations have lines for hooks: "invoke shell command when occurs", with information passed to the command by various means (parameters, environment variables, etc.). Some programs allow specification of I/O targets as pipes to or from shell commands. There is a _lot_ of "magic behavior" in bash. Debian bug #762839 mentions how bash still imports shell functions from environment variables with magic names, even when called as sh. The --posix option seems something of a joke. dash has some of this as well (in particular, it interprets CDPATH) but not nearly as much, and it's much less likely to gain more in the future. I would support a move to dash as sh, but it's not primarily for security per se but for general cleanliness: bash as sh does more to encourage the proliferation of "presumptive bashisms" and has much more potential for future breakage in central system areas. I believe this is more in line with Arch's "Simplicity" and "Code-correctness over convenience" principles than conflating the needs of interactive and whole-system-default shells for convenience's sake, especially if bash is a moving target regarding which features might be enabled that might interfere with global functionality. I would not support a move of the _packaging_ system to another sh, because that's explicitly documented to use bash as its main scripting language and relies on its extended features, and the potential complications are better contained. I don't think that's relevant unless the current packaging system assumes that bash can be invoked as sh. The case of interactive SSH is separate, because that depends on the user's interactive shell, not sh. The case of machine SSH in which the target account's shell is sh falls loosely into the program-program interoperation category. On my own desktop system, when I realized sh was bash recently I immediately relinked it to dash and intend to keep it that way as long as I reasonably can (I assume some things may break, in the current state; I'm willing to deal with that on my own for now). ---> Drake Wilson
Re: [arch-general] A good time to switch to dash as /bin/sh?
On Fri, Sep 26, 2014 at 8:13 PM, Martti Kühne wrote: > On Fri, Sep 26, 2014 at 2:06 PM, Mailing Lists > wrote: >> >> Even if we agree to shift /bin/sh to dash, I'm not sure that it'll make >> that much of a difference. From what I've read, most of the problems >> come from CGI scripts which invoke bash, and ssh post-authentication. >> I'm not saying that these are the only vectors of attack, no, but these >> are the ones which are mentioned the most. Since bash is not generally >> used remotely (except in the case of sshing to a remote machine), I The problem is on many systems /bin/sh is linked to bash -- which is why this bug is so widespread / severe. /bin/sh is "the single biggest UNIX loophole", so let's make it a bit smaller by switching it to something minimal, such as dash. >> doubt that removing bashisms from most such scripts will really make >> much difference in security. How many of these scripts are even called >> remotely? How many of them actually form an attack surface? Do you have >> any data for that? Without actually having this data, it seems >> irresponsible to talk about shifting. >> > > > Removing bashisms would not have any inpact in security but rather > enable us switching /bin/sh away from /usr/bin/bash. Which we in > general appear to agree on? Indeed. We're not talking about this specific bash bug here. We're not even talking about security specifically, although it would be an important side effect.
Re: [arch-general] A good time to switch to dash as /bin/sh?
On Fri, Sep 26, 2014, at 05:43 PM, Martti Kühne wrote: > Removing bashisms would not have any inpact in security but rather > enable us switching /bin/sh away from /usr/bin/bash. Which we in > general appear to agree on? > > cheers! > mar77i No problems there. All I'm saying is that switching should be done if the effort is worth it in terms of increased security, and if getting rid of bashisms isn't that huge a problem. Otherwise who am I to question a performance boost? -- Cheers! Savya
Re: [arch-general] A good time to switch to dash as /bin/sh?
On Fri, Sep 26, 2014 at 2:06 PM, Mailing Lists wrote: > > Even if we agree to shift /bin/sh to dash, I'm not sure that it'll make > that much of a difference. From what I've read, most of the problems > come from CGI scripts which invoke bash, and ssh post-authentication. > I'm not saying that these are the only vectors of attack, no, but these > are the ones which are mentioned the most. Since bash is not generally > used remotely (except in the case of sshing to a remote machine), I > doubt that removing bashisms from most such scripts will really make > much difference in security. How many of these scripts are even called > remotely? How many of them actually form an attack surface? Do you have > any data for that? Without actually having this data, it seems > irresponsible to talk about shifting. > Removing bashisms would not have any inpact in security but rather enable us switching /bin/sh away from /usr/bin/bash. Which we in general appear to agree on? cheers! mar77i
Re: [arch-general] A good time to switch to dash as /bin/sh?
On Fri, Sep 26, 2014, at 05:05 PM, lolilolicon wrote: > The grep would find some false positives -- e.g., some perl script might > include #!/bin/sh in its body (such as findimagedupes). > > With dash you don't really need -p, which is more strict. > > The following will reduce the count drastically: > > #!/bin/sh > for f in /usr/bin/*; do > test -f "$f" || continue > sed -nr ' > /^#!/!d > \@^#![[:space:]]*/bin/(env[[:space:]]+)?sh\>@q1 > q > ' "$f" || checkbashisms -f "$f" > done > > This finds 259 instances for me, of which 208 instances are from a > *single* script /usr/bin/libtool -- which apparently really relies on > bash. > > Among The other instances of bashism, many are false positives (if we > had removed -f from the checkbashisms command line, some could have been > detected), but some are real, such as /usr/bin/bzgrep and /usr/bin/xbmc, > but they're mostly an easy fix for upstream. > > > Assuming that these bashisms all come from upstream, patching > > and maintaining them would be a chore. > > From my inspection above, bashism is really not that wide spread. Even if we agree to shift /bin/sh to dash, I'm not sure that it'll make that much of a difference. From what I've read, most of the problems come from CGI scripts which invoke bash, and ssh post-authentication. I'm not saying that these are the only vectors of attack, no, but these are the ones which are mentioned the most. Since bash is not generally used remotely (except in the case of sshing to a remote machine), I doubt that removing bashisms from most such scripts will really make much difference in security. How many of these scripts are even called remotely? How many of them actually form an attack surface? Do you have any data for that? Without actually having this data, it seems irresponsible to talk about shifting. If you do, however, then I'd be very interested in viewing it. Disclaimer: I have no security/programming credentials, I just script a bit in my spare time. -- Cheers! Savya
Re: [arch-general] A good time to switch to dash as /bin/sh?
On Fri, Sep 26, 2014 at 6:06 PM, Mailing Lists wrote: > > i just ran the "checkbashisms" script from the AUR on my /usr/bin using > the command from the wiki: > > # checkbashisms -f -p $(grep -rlE '^#! ?/bin/(env )?sh' /usr/bin) > > which revealed 470 instances of putative bashisms in scripts using > #!/bin/sh. The grep would find some false positives -- e.g., some perl script might include #!/bin/sh in its body (such as findimagedupes). With dash you don't really need -p, which is more strict. The following will reduce the count drastically: #!/bin/sh for f in /usr/bin/*; do test -f "$f" || continue sed -nr ' /^#!/!d \@^#![[:space:]]*/bin/(env[[:space:]]+)?sh\>@q1 q ' "$f" || checkbashisms -f "$f" done This finds 259 instances for me, of which 208 instances are from a *single* script /usr/bin/libtool -- which apparently really relies on bash. Among The other instances of bashism, many are false positives (if we had removed -f from the checkbashisms command line, some could have been detected), but some are real, such as /usr/bin/bzgrep and /usr/bin/xbmc, but they're mostly an easy fix for upstream. > Assuming that these bashisms all come from upstream, patching > and maintaining them would be a chore. >From my inspection above, bashism is really not that wide spread.
Re: [arch-general] A good time to switch to dash as /bin/sh?
On Fri, Sep 26, 2014, at 02:52 PM, lolilolicon wrote:
> On Fri, Sep 26, 2014 at 4:20 PM, Martti Kühne wrote:
> [...]
> > Despite that I'm still not convinced as to why
> > the issue in question is such a big deal, I must say it's unlikely
> > we're better off with a less active, less used shell.
>
> Put simply, bash has too much bloat. That includes obscure dark corners
> like function export/import, where bash interprets an ENV whose value
> starts with '() {' as a function definition. And this behavior is not
> inhibited even when bash is invoked as sh.
>
> In contrast, a minimal implementation of the POSIX shell implements only
> such well defined features. That means security people know where to
> look for bugs. Being Minimal in itself also promises fewer bugs.
>
> I do not have hard numbers about dash; but I think it's to be trusted.
> It has a long history. It's maintained. It's not being actively
> developed, because it does not have features to add, and it does not
> have bugs to fix that resulted from added features. It's used by
> debian-based distros as /bin/sh so it's not exactly lacking testing.
>
> The only real "cultural incompatibility" I see in Arch's switching to
> dash as /bin/sh is that dash is "too Debian". dash is "feature
> complete"; it's not going to push the POSIX shell standard forward. That
> it *follows* the standard. That it's not bleeding edge.
>
> But who wants /bin/sh to bleed?
i just ran the "checkbashisms" script from the AUR on my /usr/bin using
the command from the wiki:
# checkbashisms -f -p $(grep -rlE '^#! ?/bin/(env )?sh' /usr/bin)
which revealed 470 instances of putative bashisms in scripts using
#!/bin/sh. Assuming that these bashisms all come from upstream, patching
and maintaining them would be a chore.
To be clear, I'm not against what you're saying, I'm just saying that
making and maintaining that transition would be difficult. I have 761
packages installed on my system, and I get 470 instances of putative
bashisms. I'm guessing there will be others for whom this number will be
far greater.
--
Cheers!
Savya
Re: [arch-general] A good time to switch to dash as /bin/sh?
On Fri, Sep 26, 2014 at 4:20 PM, Martti Kühne wrote:
[...]
> Despite that I'm still not convinced as to why
> the issue in question is such a big deal, I must say it's unlikely
> we're better off with a less active, less used shell.
Put simply, bash has too much bloat. That includes obscure dark corners
like function export/import, where bash interprets an ENV whose value
starts with '() {' as a function definition. And this behavior is not
inhibited even when bash is invoked as sh.
In contrast, a minimal implementation of the POSIX shell implements only
such well defined features. That means security people know where to
look for bugs. Being Minimal in itself also promises fewer bugs.
I do not have hard numbers about dash; but I think it's to be trusted.
It has a long history. It's maintained. It's not being actively
developed, because it does not have features to add, and it does not
have bugs to fix that resulted from added features. It's used by
debian-based distros as /bin/sh so it's not exactly lacking testing.
The only real "cultural incompatibility" I see in Arch's switching to
dash as /bin/sh is that dash is "too Debian". dash is "feature
complete"; it's not going to push the POSIX shell standard forward. That
it *follows* the standard. That it's not bleeding edge.
But who wants /bin/sh to bleed?
Re: [arch-general] A good time to switch to dash as /bin/sh?
On Fri, Sep 26, 2014 at 10:14 AM, lolilolicon wrote:
> On Fri, Sep 26, 2014 at 3:11 PM, Martti Kühne wrote:
>> Arch cannot realistically switch away from bash as long as both its
>> package management depends on it for both package creation and package
>> management tasks.
>
> But we can switch away from using bash as /bin/sh.
Uhm, okay. But let me throw this in: Bash is actively developped, the
patch for CVE-2014-{6271,7169} was on my system before I even learned
about these problems. Despite that I'm still not convinced as to why
the issue in question is such a big deal, I must say it's unlikely
we're better off with a less active, less used shell.
cheers!
mar77i
Re: [arch-general] A good time to switch to dash as /bin/sh?
On Fri, Sep 26, 2014 at 3:11 PM, Martti Kühne wrote: > Arch cannot realistically switch away from bash as long as both its > package management depends on it for both package creation and package > management tasks. But we can switch away from using bash as /bin/sh.
Re: [arch-general] multiarch support like debian, pro and cons?
On Fri, Sep 26, 2014 at 1:08 AM, Ranomier wrote: > I wrote my idea first on the irc, but i think here is a better place. > > The idea is to give up multiarch repo and make pacman and archlinux capable > for real multiarch support > > That means u could install a 32bit package from the normal repos core, > extra, community usw and not from multilib repo in 64bit arch. (example: > pacman -S firefox:i386) > I personally find this approach better and more transparent than what Debian does. I'm not sure how they manage multiarch, but on debian I also cannot tell IF a given program uses 64 bit code at a time. I like how Arch's configuration is consistent and that in any given context, I can be certain it's using the bloated pointer type. I wanted to go as far as calling that approach of Debian names, but it's just not right now fitting into the tone of this email, so I leave that open to the reader. cheers! mar77i
Re: [arch-general] mkinitcpio debugging with systemd
On Thu, Sep 25, 2014 at 7:21 PM, Tobias Hunger wrote: > Hi Martti, > > I did mention that I have been playing with the hooks and systemd in my > initial mail. At least I thought that would be clear. Sorry if it was not. > I will try to make that more clear next time. Was my first post here, I > only joined this list recently. > > My question about how to open a debug shell is not effected by my changes > in any way. > That said, I'm sorry. I should have just told you to test without your changes and been done with it. cheers! mar77i
Re: [arch-general] A good time to switch to dash as /bin/sh?
Arch cannot realistically switch away from bash as long as both its package management depends on it for both package creation and package management tasks. cheers! mar77i
