**** BEGIN LOGGING AT Mon May 12 02:59:59 2014
May 12 11:35:34 <DocScrutinizer05> awesome¡
May 12 11:35:38 <DocScrutinizer05> [2014-05-11 Sun 22:28:14] <thiago> Qt 5.3 will abort execution if it detects it's suid.
May 12 11:35:40 <DocScrutinizer05> [2014-05-11 Sun 22:28:18] <DocScrutinizer05> won't stay
May 12 11:35:41 <DocScrutinizer05> [2014-05-11 Sun 22:29:11] <DocScrutinizer05> it's a blatant exposure of poor understanding of basic system design principles
May 12 11:35:58 <DocScrutinizer05> [2014-05-11 Sun 22:34:09] <DocScrutinizer05> when my user "admin" can't use Qt-based binaries admin:root -rwsrwx--- then that Qt libs are considered broken and will have to change eventually
May 12 11:36:12 <DocScrutinizer05> [2014-05-11 Sun 22:36:34] <thiago> DocScrutinizer05: well, fair enough, but the change is made
May 12 11:36:13 <DocScrutinizer05> [2014-05-11 Sun 22:36:42] <thiago> DocScrutinizer05: bring this up in the mailing list or patch Qt
May 12 11:37:51 <larsc> I think the reason why it does this is because you can inject abitrary code into a QT application
May 12 11:38:16 <larsc> so if you have qt application with suid that's a root exploit
May 12 11:38:28 <DocScrutinizer05> well, then Qt has to make sure this doesn't become a threat
May 12 11:39:15 <DocScrutinizer05> larsc: *everything* which has suid despite the guy who set it didn't know shit *is* an exploit already. I don't need Qt for that
May 12 11:40:07 <DocScrutinizer05> Qt trying to fix/enforce plain common sense sysop best practice
May 12 11:40:36 <DocScrutinizer05> user is NOT supposed to mess with suid. But *when* I do, I expect I get what I asked for
May 12 11:42:44 <DocScrutinizer05> it's kinda like - when I do a 'rm foo' - system answers with "no you don't"
May 12 11:46:08 <DocScrutinizer05> when those guys are concerned about any possible attack/exploit vector in their libs, they better a) fix that flaw, to start with, or b) clearly *document* the problem in their specs/docs and maybe even provice a qt-chmod to override standard chmod by placing it into /usr/local/bin/ that WARNS as soon as I try to set suid of any program that uses Qt libs
May 12 11:47:45 <DocScrutinizer05> I mean, who and how been _setting_ +s on that Qt-binary?? and why? And how he gained the permission to do so? Does Qt lib know about all those details? No!
May 12 11:48:26 <DocScrutinizer05> instead they seem to assume every idiot could set a binary +s
May 12 11:48:53 <DocScrutinizer05> and it's always either rogue or done by idiots. Makes no sense in my book
May 12 11:49:21 <larsc> that is valid assumption though
May 12 11:49:46 <DocScrutinizer05> no, that's an arrogant and idiotic assumption
May 12 11:53:00 <DocScrutinizer05> and it's patronizing all sysops with a single synapse left over to think about what they do, who all KNOW that on their system NOBODY can set suid to arbitrary binaries without them nodding that off
May 12 11:54:03 <DocScrutinizer05> I might agree when you demand package managers to pop up a warning on installing any binary that is +s
May 12 11:54:20 <DocScrutinizer05> I might agree when you demand warning in chmod when doing +s
May 12 11:55:20 <DocScrutinizer05> I totally agree when you say that removable media ALWAYS need to get mounted -o nosuid and sysop shall take care to enforce this
May 12 11:56:03 <DocScrutinizer05> I absolutely oppose to design a system on the premise that sysop doesn't know what s7he is doing
May 12 11:56:33 <DocScrutinizer05> and to overrun any decisions sysop made
May 12 11:57:47 <bencoh> qt writing clear specs/doc about what it does ? sounds like dreamland ;)
May 12 11:57:57 <DocScrutinizer05> indead
May 12 11:58:38 <DocScrutinizer05> Qt even doing "the right thing[TM]" every now and then sounds like a phantasm
May 12 12:00:46 <DocScrutinizer05> I had *exactly* same dispute with Suse maintainers several years ago, about hwclock binary doing a check for UID (!!! not EUID even) = 0, and then aborting with "You must be root to run hwclock!"
May 12 12:01:16 <DocScrutinizer05> they tried to tell me it's a feature. Next suse release they had fixed dat shite according to my rant
May 12 12:06:41 <DocScrutinizer05> since then it works like supposed to: http://privatepaste.com/a0c1d92a21
May 12 12:32:50 <DocScrutinizer05> yesterday some dude claimed "running Qt as root isn't the problem, setting suid bit is the problem" - what the heck a rationale is that?
May 12 12:37:48 <larsc> it's not a root exploit if you are already root...
May 12 12:40:39 <DocScrutinizer05> exactly, and suid MAKES YOU already root when you're started
May 12 12:41:03 <larsc> exactly
May 12 12:41:55 <larsc> you don't seem to understand the purpose of suid applications
May 12 12:51:35 <DocScrutinizer51> ooh, *I* don't understand SUID?
May 12 12:54:27 <DocScrutinizer51> YOU seem to think you and Qt devels are the only ones to define what's allowed to SUID and what's not
May 12 12:54:27 <DocScrutinizer51> you have no idea about the purpose of the SUID apps on MY system, heck not on anybody's
May 12 12:55:34 <DocScrutinizer51> the purpose of suid is clearly specified in POSIX
May 12 12:58:17 <DocScrutinizer51> when you think your particular app on your system is not appropriate to get +s - simply don't set +s on it. Nothing else for you to worry about, no matter if you're user, sysop, or devel
May 12 13:12:48 <larsc> if you don't understand why it is not a problem to run a qt application as root, but it is a problem to have a suid qt application, you don't understand suid
May 12 13:13:01 <DocScrutinizer51> aha
May 12 13:13:43 <DocScrutinizer51> don't you think that same rationale applies to those who invented suid?
May 12 13:14:45 <DocScrutinizer51> and of course *you* are way smarter and know better about suid than the system architects who invented it
May 12 13:16:01 <DocScrutinizer51> I don't see the slightest difference between sudo foobar and a plain foobar with foobar set +s
May 12 13:16:21 <larsc> yea
May 12 13:16:25 <larsc> what I'm saying ;)
May 12 13:16:43 <DocScrutinizer51> actually no app is supposed to make assumptions why it has root permissions
May 12 13:18:12 <DocScrutinizer51> if it can't handle root thewn it shall drop it. Otherwise fix your app instead of trying to fix sysop's decisions
May 12 13:19:15 <DocScrutinizer51> your whole argumentation is just a list of "I know better and you don't gtok it"
May 12 13:19:35 <DocScrutinizer51> grok, even
May 12 13:20:27 <larsc> if you have a suid qt application any user on the system can run abitrary code with root rights
May 12 13:20:34 <larsc> that's a root exploit
May 12 13:21:12 <larsc> even the user nobody
May 12 13:21:19 <larsc> or the user www
May 12 14:24:44 <DocScrutinizer51> look, I'll make it simple for you: do you think a qt app is worse (inferior coding) than less(1)? do you agree that less when set +s allows everybody to "exploit root"? Do you know of any ticket that requests implementing a check for suid into less? if no, please tell me why you think that's the case
May 12 14:26:09 <DocScrutinizer51> if you answer 1. Q with yes or 2nd with no then please elaborate
May 12 14:27:18 <larsc> less doesn't allow an unprivileged user to run arbitrary code, qt does
May 12 14:27:19 <DocScrutinizer51> and about your previous explanation: that's not a root exploit, that's how suid is supposed to work
May 12 14:27:29 <larsc> no, it's not
May 12 14:27:56 <larsc> suid is about letting a unpriviledged user run a very specific amount of code with root rights
May 12 14:28:10 <larsc> like ping getting access to the network interface
May 12 14:28:14 <larsc> nothing more nothing less
May 12 14:28:58 <larsc> qt applications allow you to load arbitrary code
May 12 14:29:21 <larsc> means any user can run any code with root permissions
May 12 14:29:27 <larsc> that's a root exploit
May 12 14:31:35 <larsc> setting suid on a qt application is like setting suid on bash
May 12 14:33:33 <DocScrutinizer51> please elaborate
May 12 14:33:34 <DocScrutinizer51> I think less is perfectly capable of running whatever I pass to !command
May 12 14:34:40 <DocScrutinizer51> and if you still have problems then s/less/bash/ I don't care, the line of rationale stays the same
May 12 14:35:26 <DocScrutinizer51> none of those binaries checks suid. Why does Qt?
May 12 14:37:35 <DocScrutinizer51> I tell you: because of Qt devels have a good idea of the inferior quality of their code and they try to fix that flaw by anept means
May 12 14:37:51 <radekp> DocScrutinizer51: maybe because Qt is library and the coder who uses it does not know all the features and implications? -> just my guess...
May 12 14:38:37 <DocScrutinizer51> then the library or the doc of library is fubar
May 12 14:42:08 <larsc> exactly, qt devs know that qt allows you to run arbitrary code, that's why it won't run with suid
May 12 14:45:16 * radekp wonders if running any dynamicaly linked suid program is safe... e.g. if i change LD_LIBRARY_PATH to dir with my evil libXXX.so
May 12 14:45:47 <larsc> the linker will it ignore it when the suid bit is set
May 12 14:45:54 <larsc> but QT does not
May 12 14:46:52 <radekp> ahh oki
May 12 15:09:29 <DocScrutinizer05> larsc: (qt devs know that qt allows you to run arbitrary code) and bash and less devs didn't? Do you really think Qt devs are sooooo much smarter than the devs who made bash and less and whatnot else?
May 12 15:12:42 <DocScrutinizer05> it all boils down that evetrybody dev knows about bash being able to execute code arbitrary code. And *some* even know about less being able to do same. But seems you imply *nobosy* knows about Qt lib also allows this
May 12 15:12:49 <DocScrutinizer05> nobody, even
May 12 15:13:33 <DocScrutinizer05> I wonder if you don't see where's the problem in this situation. It's not suid, it's fux0red docs of Qt libs, nothing else
May 12 15:14:33 <DocScrutinizer05> and btw Qt lib devels *could* come up with methods to make their lib save, if only they would care
May 12 15:15:40 <DocScrutinizer05> but not allowing suid is for sure an inept and silly futile effort to make stuff safer
May 12 15:16:22 <DocScrutinizer05> since I can run arbitrary code via a flawed Qt-lib based binary no matter if it gained root permissions via suid or sudo
May 12 15:17:54 <DocScrutinizer05> and before you again start claiming I have no clue about what I'm telling: you're aware that sudo can allow root for a single particular program, even with particular parameters. Are you?
May 12 15:19:16 <DocScrutinizer05> it's absolutely not different to suid, except you need to write "sudo " in front of the command. And the way to enable suid is differnet from config method used for sudo, but both need root permissions to get done
May 12 15:20:18 <DocScrutinizer05> so no elementary relevant difference in config/management preconditions and methods either
May 12 15:22:06 <DocScrutinizer05> (btw sudo does drop of [LD_PRELOAD et al] envs just like suid, in effect)
May 12 15:23:09 <larsc> bash does drop it's privileges again if it sees that it has the suid bit set
May 12 15:23:31 <larsc> and I think it would be a good idea for less to not allow ! if the suid bit is set
May 12 15:24:02 <larsc> again, in order to run a binary as root you first need to be root
May 12 15:24:11 <DocScrutinizer05> the system architects had their thoughts sorted when they designed that stuff, you don't need to implement special checks into Qt to fight anticipated fictious trheats from suid
May 12 15:24:15 <larsc> with a suid application you do not need to be root
May 12 15:25:06 <DocScrutinizer05> do you really think I'm interested in first class lessons like the last two lines from you?
May 12 15:25:38 <larsc> apparently you are not
May 12 15:26:12 <DocScrutinizer05> definitely not. A statement like " in order to run a binary as root you first need to be root" is redundant BS
May 12 15:27:50 <DocScrutinizer05> when your frigiin lib is allowing to execute arbitrary code then maybe it's not root-safe, which means you should do like bash and drop privileges immediately
May 12 15:28:00 <DocScrutinizer05> checking for suid is bullshit
May 12 15:28:46 <larsc> that's why you don't write system level code ;)
May 12 15:29:05 <DocScrutinizer05> there's probably a dozen ways to grant root permissions to a process, and checking for only one particular one of them is idiotic
May 12 15:29:22 <DocScrutinizer05> that's why you got no girlfriend
May 12 15:30:00 <misc> that's a very mature answer, nice 
May 12 15:30:30 <DocScrutinizer05> it's the only correct answer to "that's why you don't write system level code ;)"
May 12 15:31:03 <DocScrutinizer05> it's as void of any meaning as the statement it been the answer to
May 12 15:31:53 <larsc> you call people idiots for understanding the security implications of the suid bit
May 12 15:32:20 <DocScrutinizer05> I could start questing this dude why the heck he thinks I don't, and how that's related, and why he needs to be so arrogant and ignorant, but I think that leads nowhere
May 12 15:33:08 <DocScrutinizer05> no, I call the activity idiotic
May 12 15:34:13 <DocScrutinizer05> and I do so since the activity clearly exposed plain to see for everybody that the implications are NOT understood
May 12 15:34:14 <larsc> so understanding the security implications of the suid bit is idiotic?
May 12 15:34:43 <DocScrutinizer05> by the one who thought checking for suid makes *any* sense
May 12 15:35:16 <DocScrutinizer05> there are better correct way to acjhieve what was the probably aim, and I quoted them all
May 12 15:36:24 <DocScrutinizer05> while my opponent insists on insulting me personaly by teaching me BS like "in order to run a binary as root you first need to be root"
May 12 15:36:37 <DocScrutinizer05> and thinks he made a point with such statement
May 12 15:36:49 <DocScrutinizer05> hey, did you hear? water is wet
May 12 15:37:58 <DocScrutinizer05> and to exploit a process with root permissions that allows execution of arbitrary code, it **IS* **ABSOLUTELY** irrelevant how the process gained root permissions
May 12 15:38:30 <DocScrutinizer05> you either fix your code, or you drop permissions
May 12 15:38:33 <DocScrutinizer05> period
May 12 15:41:23 <rah> radekp: LD_LIBRARY_PATH is unset when you execute an suid program
May 12 15:42:22 <larsc> as I said it is not a problem if the root user can run arbitrary code as root, since he already is root. It is a problem if a unprivileged user can run abitrary code as root
May 12 15:43:03 <DocScrutinizer05> as I daid there are a dozen ways for a process to get root permissions, checking for just one of them is ... idiotic
May 12 15:44:09 <larsc> it's a very sensible thing to do
May 12 15:44:27 <DocScrutinizer05> obviously you have no idea how suid and permissions at large work. Are you even aware that suid doesn't necessarily set a process to "root"? it sets the process to permissions of binary file OWNER
May 12 15:46:28 <larsc> I'm very well aware of that
May 12 15:46:52 <DocScrutinizer05> it's NOT about "who the user is", you got no idea about your user. It's all about the permissions a process has or has not
May 12 15:48:27 <DocScrutinizer05> nobody "is root", a shell might have root permissions, inherited from its parent process or whatever
May 12 15:49:08 <DocScrutinizer05> a process in general may or may not have root or any other permissions, and they are granted to the process by system means
May 12 15:49:37 <DocScrutinizer05> one of them (and really one of many) is suid
May 12 15:51:01 <larsc> ok, lets agree to disagree
May 12 15:51:32 <DocScrutinizer05> I don't need to agree on anything, I'm listing facts
May 12 15:52:02 <DocScrutinizer05> you can either prove me wrong or continue with rant like " in order to run a binary as root you first need to be root"
May 12 15:53:08 <larsc> well, that's a fact isn't it?
May 12 15:55:38 <DocScrutinizer05> facts: suid bit sets process to file owner permissions. nothing else in linux does a check for suid, despite many programs are "more dangerous" than Qt. Setting suid bit needs root permissions. 
May 12 15:55:57 <DocScrutinizer05> fact: sudo does exactly same
May 12 15:56:56 <DocScrutinizer05> fact: a similar nonsense in hwclock got cancelled a few years ago after I complained to the devels
May 12 15:57:44 <DocScrutinizer05> fact: nowhere in possix it's written that suid bit needs check, neither in any unix tutorial
May 12 15:58:01 <rah> fact: insecure people get defensive
May 12 15:58:15 <DocScrutinizer05> yeah, obviously
May 12 15:58:36 <DocScrutinizer05> dang, what's wrong with my ignore list
May 12 16:00:48 <larsc> the hwclock thing was actually completely different
May 12 16:00:57 <DocScrutinizer05> not at all
May 12 16:01:23 <larsc> and the check there made no sense, since hwclock does not allow privilege escalation
May 12 16:01:46 <DocScrutinizer05> but hey, you probably had to say that, since you agreed with yourself to disagree with me
May 12 16:02:33 <DocScrutinizer05> there IS NOT privilege escalation in Qt! GET THAT!
May 12 16:03:01 <DocScrutinizer05> there's a simple execution of code not supposed to be there
May 12 16:03:26 <DocScrutinizer05> the privileges already got escalated before, in one of a dozen ways you cannot control
May 12 16:04:43 <DocScrutinizer05> executing arbitrary code that the user or devel doesn't really expected to get executed is bad enough, but it's no privilege escalation, it's a completely different bug
May 12 16:10:21 <larsc> arbitary code execution is in this case a feature of qt, whether that is a sensible feature or not...
May 12 16:10:37 <DocScrutinizer05> that doesn't mean a thing
May 12 16:11:04 <DocScrutinizer05> it makes Qt same class like bash and less
May 12 16:11:25 <DocScrutinizer05> those don't counteract suid
May 12 16:11:32 <DocScrutinizer05> why does Qt?
May 12 16:11:50 <larsc> bash does, less probably should
May 12 16:12:14 <larsc> and qt does it because it is a sensible thing to do
May 12 16:12:18 <DocScrutinizer05> no they both don't, bash drops privileges which is sth different than checking for suid
May 12 16:13:19 <DocScrutinizer05> and actually I'm not even sure if bash really does drop privileges, but I'm willing to take it as fact since it doesn't make a difference
May 12 16:13:37 <DocScrutinizer05> dropping privileges is OK. checking for suid is nonsense
May 12 16:14:23 <DocScrutinizer05> btw I doubt bash drops privileges since that would mean you child shell has no root permissions anymore
May 12 16:15:15 <DocScrutinizer05> you maybe mixed that up with suid on script files.
May 12 16:15:35 <misc> http://blog.cmpxchg8b.com/2013/08/security-debianisms.html
May 12 16:16:35 <DocScrutinizer05> ok, bash does
May 12 16:19:08 <DocScrutinizer05> still it stands: dropping privileges is not as idiotic as exiting the process
May 12 16:19:55 <DocScrutinizer05> and doing that in a lib is particularly nasty
May 12 16:22:01 <misc> you would still be ranting if QT was dropping privileges rather than stopping, because that would still not be what you want, so I do not really see what it changes in practice for you, or why you would prefer any solution
May 12 16:23:21 <DocScrutinizer05> well, see >>Indeed, Chet Ramey (bash author and maintainer) explains that the purpose of this is to prevent "bogus system(3) calls in setuid executables"<<
May 12 16:23:37 <DocScrutinizer05> show me the system() call that uses a Qt binary 
May 12 16:24:47 <DocScrutinizer05> it's meant to make bash secure for system() calls
May 12 16:25:28 <DocScrutinizer05> which in turn would mean that Qt wouldn't need to bother anymore, if it was only for system() calls in Qt lib, right?
May 12 16:26:18 <DocScrutinizer05> since bash already fixed that for Qt
May 12 16:27:49 <DocScrutinizer05> no way bash itsyelf creates any vulnerability from being +s that the sysop wasn't perfectly aware of. IOW bash itself is safe, it takes care of other binaries that are suid and use system()
May 12 16:29:29 <DocScrutinizer05> it's the system() call that invokes bash in a already suid environment. Since that doesn't apply to Qt (Qt doesn't get invoked by other suid processes via system() ) there's no need for Qt to do what bash does
May 12 16:30:20 <DocScrutinizer05> thanks for the pointer, misc
May 12 16:33:09 <DocScrutinizer05> again, a last time: suid is not meant to get arbitrarily messed around with by user, it needs root permissions to set +s on any binary. The one who does that is supposed to know about the implications, nothing a lib devel hast to or even may care about
May 12 16:37:06 <DocScrutinizer05> the correct way to handle this problem would be Qt dropping privileges before any function call that might execute arbitrary code, exactly like 
May 12 16:37:08 <DocScrutinizer05> 489   if (running_setuid && privileged_mode == 0)
May 12 16:37:10 <DocScrutinizer05>  490     disable_priv_mode ();
May 12 16:37:55 <DocScrutinizer05> and actually only the thread that gets spawned to execute the code should do that
May 12 16:38:39 <DocScrutinizer05> (yeah I know threads probably can't have their own permissions when they share namespace etc)
May 12 16:42:42 <DocScrutinizer05> misc: ((I do not really see what it changes in practice for you)) I think a Qt program should be able to run suid when sysop decided to run it suid. No matter if it's a binary foobar nobody:users r-sr-xr-x; or a binary listsyslog root:admin rwsr-x---
May 12 16:44:50 <DocScrutinizer05> I might even use less instead of listsyslog, and there are even ways to forbid calls to system() in the less binary run by admin with suid root
May 12 16:46:47 <DocScrutinizer05> I'm aware Qt might be less safe than e.g. "less" or even "more" when set suid, but I don't expect the devels to *forbid* me to do it nevertheless, since again: setting suid is a sysop domain thing, not supposed to get messed with by arbitrary users
May 12 16:49:26 <DocScrutinizer05> misc: thanks to your link I got aware that I wouldn't even need to take care about less' "!" command and forbidding system(), since bash already takes care for me on my system.
May 12 16:50:57 <DocScrutinizer05> executing less: ! fobaar -> system() -> bin/sh ak bash -> foobar would drop root privs in bash already, so it's perfectly safe
May 12 17:44:57 <DocScrutinizer05> ((<larsc> and I think it would be a good idea for less to not allow ! if the suid bit is set)) No! If anything, less should drop privileges before executing "!" command nevertheless when set +suid. But as explained by http://blog.cmpxchg8b.com/2013/08/security-debianisms.html it doesn't need to worry/care at all since that problem got handled in /bin/sh and system()
May 12 17:46:28 <dos1> *reading backlog* I like DocScrutinizer05's comparison with sudo
May 12 17:46:48 <dos1> sudo is exactly the same threat as suid, and I even exploited it few times by myself :P
May 12 20:20:57 <DocScrutinizer05> ((<larsc> and qt does it because it is a sensible thing to do)) I still haven't heard a single argument why it allegedly was "a sensible thing to do" when  a lib overrides deliberate and well thought decisions made by sysop. I feel patronized by a lib devel who thinks he knows better than me what should get done on my system. There is NO reason to *forbid* suid, since nobody is forced to *use* suid or have it set on any binary 
May 12 20:20:58 <DocScrutinizer05> when s/he doesn't want it to be set there
May 12 20:24:35 <DocScrutinizer05> and the whole concept is obviously flawed, see "foobar-bninary nobody:users r-sr-xr-x" which will get rejected by Qt despite it's meant to make my system even saver. You _cannot_ justify this. The idea to exit process on suid-bit detected been born in a booze
May 12 20:25:31 <DocScrutinizer05> safer*
May 12 20:26:17 <DocScrutinizer05> and damn that must've been cheap booze
May 13 00:31:39 <pabs3> rebooting openmoko.org for a kernel upgrade
**** ENDING LOGGING AT Tue May 13 02:59:58 2014