=================================== #fedora-meeting: FESCO (2013-05-29) ===================================
Meeting started by t8m at 18:01:09 UTC. The full logs are available at http://meetbot.fedoraproject.org/fedora-meeting/2013-05-29/fesco.2013-05-29-18.01.log.html . Meeting summary --------------- * init process (t8m, 18:01:35) * #1113 Using PIE by default on AMD64 (t8m, 18:04:36) * proposal is rejected (+2 -5 0:2) (t8m, 18:45:03) * #1117 Generalize policy about privilege escalation and Administrator user accounts (t8m, 18:46:51) * no proposal yet (t8m, 18:49:05) * Anybody is encouraged to create a concrete proposal for generalizing the policy (t8m, 18:52:13) * Next week's chair (t8m, 18:54:13) * ACTION: mitr to chair FESCo next week (t8m, 18:58:37) * Open Floor (t8m, 19:00:14) Meeting ended at 19:21:26 UTC. Action Items ------------ * mitr to chair FESCo next week Action Items, by person ----------------------- * mitr * mitr to chair FESCo next week * **UNASSIGNED** * (none) People Present (lines said) --------------------------- * t8m (80) * mitr (43) * nirik (42) * kseifried (23) * bress (23) * sgallagh (22) * halfie (20) * abadger1999 (19) * notting (17) * jwb (16) * pjones (11) * zodbot (9) * mmaslano (7) * LinuxCode (1) Generated by `MeetBot`_ 0.1.4 .. _`MeetBot`: http://wiki.debian.org/MeetBot ---------------- 18:01:09 <t8m> #startmeeting FESCO (2013-05-29) 18:01:09 <zodbot> Meeting started Wed May 29 18:01:09 2013 UTC. The chair is t8m. Information about MeetBot at http://wiki.debian.org/MeetBot. 18:01:09 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic. 18:01:15 <t8m> #meetingname fesco 18:01:15 <zodbot> The meeting name has been set to 'fesco' 18:01:22 <t8m> #chair abadger1999 jwb mitr mmaslano notting nirik pjones t8m sgallagh 18:01:23 <zodbot> Current chairs: abadger1999 jwb mitr mmaslano nirik notting pjones sgallagh t8m 18:01:31 <sgallagh> Nobody here but us chickens 18:01:33 <nirik> morning everyone. 18:01:34 <mitr> Hello 18:01:35 <t8m> #topic init process 18:01:37 <abadger1999> Greetings 18:01:43 <t8m> Hello everyone 18:01:45 <pjones> hello 18:02:29 * notting is here 18:02:34 <mmaslano> hi 18:03:43 <t8m> should we wait a short while for jwb? 18:04:00 <jwb> hi, sorry 18:04:33 <t8m> ok let's start 18:04:36 <t8m> #topic #1113 Using PIE by default on AMD64 18:04:44 <t8m> .fesco 1113 18:04:45 <zodbot> t8m: #1113 (Using PIE by default on AMD64) – FESCo - https://fedorahosted.org/fesco/ticket/1113 18:05:19 <nirik> so, I think we are all agreed that we don't want to do this for f19 right? so, it would be f20... and it would need a mass rebuild. So, I don't think we need to be very hasty here... we can take time and gather info, etc. 18:05:26 <sgallagh> In general, I continue to favor just leaving this decision up to the package maintainers, except for the previously-agreed categories. 18:05:47 <t8m> So Jakub seems firmly opposed to have PIE on by default. 18:05:54 <pjones> t8m: I tend to defer to him in these situations. 18:05:58 <t8m> nirik, I agree that we do not have to be hasty 18:06:51 <mitr> I still haven't seen a compelling set of applications that would be noticeably harmed by the ~3-4% penalty if the default were filpped. 18:07:17 <jwb> basically, all of them. 18:07:24 <mitr> OTOH the side effect of invalidating prelink does seem to be noticeable (... on LibreOffice, where we could debate whether it shouldn't be _hardened_build anyway) 18:07:25 <nirik> mitr: it's not actually clear if it is 3-4% tho... 18:07:56 <mitr> jwb: For applications that spend most of their time waiting for users' input and have a 100ms latency budget, the 3-4% don't make a difference, do they? 18:07:59 <t8m> jwb, basically none of them as 99% of code is already in shared libraries which are PIC 18:08:42 <mitr> nirik: fair point, but then again we don't know what to measure even if the methodology could be improved 18:09:13 <nirik> well, to start with, some actual fedora packages with our compiler flags, etc... 18:09:23 <jwb> right. so since people don't care because the apps are idle most of the time, we should build with -O0 so we can debug things more easily 18:09:34 <jwb> your logic doesn't really make sense 18:09:49 <t8m> on the other hand I agree with Jakub that most important for security are other things than address space randomization 18:10:30 <mitr> jwb: I can't actually see an obvious rebuttal to the -O0 argument 18:10:31 <t8m> I don't think the argument about idling is really valid, what's more important is that most of the code is already PIC 18:10:54 <jwb> mitr, that means you don't know what it does 18:10:56 <mitr> t8m: Well, yeah, "don't use C" where this discussion becomes moot 18:11:05 <pjones> jwb: I would actually *agree* with your -O0 argument, if only because we can barely ever debug anything with our debuginfo. 18:11:18 <jwb> ugh. ok, i'm done. 18:11:33 <mitr> jwb: Yeah, if it tripled the binary size or something, that would be worrisome. But, in principle, if the performace doesn't matter, then it doesn't matter. 18:11:33 <jwb> i don't agree PIE should be default everywhere and i don't think -O0 is a good idea. 18:11:45 <jwb> this is just silly 18:11:53 <sgallagh> jwb: Believe me, I agree with you. 18:12:15 <t8m> as we wouldn't forbid to opt out of the hardened build I don't think having the default flipped would be a problem for anyone though 18:12:20 <mitr> t8m: As for "most of the code being PIC", you only need one non-randomized place to override. (It does get easier if you have more of them, but not linearly) 18:12:38 <sgallagh> The irony is that the only examples I can think of that would really benefit from a 3% performance increase are the network servers that we already have on the mandatory list (apache, MariaDB, etc.) 18:12:38 * nirik is torn between just listening to jakub and trying to gather more info, but it's muddy what all that info should be. 18:12:44 <notting> given the number of customers (admittedly, not fedora) that intentionally disable selinux for real/imagined performance impact of the same order of magnitude as discussed here, I don't think we can wave away the performance impact 18:12:54 <t8m> mitr, not from the security POV but from the code efficiency 18:13:13 <mitr> sgallagh: Yes, precisely. 18:13:44 <abadger1999> notting: by the same token, we continue to ship with selinux enabled by default despite the (real or imagined) performance impact. 18:13:51 <t8m> abadger1999, +1 18:14:43 <jwb> are we seriously ignoring the entire purpose of SELinux with this argumentation? 18:14:49 <notting> abadger1999: the point is that the performance difference matters. and i think we can agree that selinux is a far far better security benefit than PIE, so we eat the cost there. i don't think PIE is a big enough benefit to counter that. 18:14:55 <abadger1999> <nod> 18:15:03 <mmaslano> yes 18:15:12 <t8m> notting, I can agree with that 18:15:14 <nirik> also, PIE is not trivially disablable. 18:15:54 <abadger1999> So really we want to know -- what is the actual performance degradation with our compilation flags +/- pie. 18:16:04 <t8m> so do we want to vote on this proposal or does somebody feel that more data can persuade him/her to change his mind? 18:16:11 <jwb> abadger1999, no 18:16:14 <t8m> abadger1999, performance degradation of what? 18:16:17 <mitr> abadger1999: Do you have a threshold in mind that would make you decide one way or the other? 18:16:25 <jwb> we want to know that and we want to know exactly how beneficial the security is 18:16:28 <nirik> abadger1999: I would like to know that yeah, but it will of course vary. 18:17:05 <t8m> I don't think you can measure any real performance degradation on regular Fedora apps as most of the performance sensitive code is already PIC 18:17:06 <abadger1999> jwb: sure -- my criteria wasn't exclusive. 18:17:15 <mitr> t8m: I'm still kind of hoping for resolution of the prelink side effect 18:17:16 <t8m> f. e. the crypto libraries 18:17:21 <notting> jwb: the pie security benefit is merely a decreased chance of pre-compiled exploits working 18:18:17 <abadger1999> mitr: I think they're mutually exclusive but I could be wrong. 18:18:26 <mitr> notting: both precompiled and individually-generated; ("precompiled" == sending the same binary to many users is where prelink makes a difference) 18:18:37 <mitr> abadger1999: they are right now, but it's just software :) 18:18:38 <abadger1999> notting: When bressers explained it to me, it sounded like more than that. 18:18:39 <pjones> notting: and I'm understanding correctly, right, that the big performance gap is at startup, not as the program runs? 18:19:14 <notting> mitr: ok, 'canned' exploits, i guess? 18:19:16 <mitr> pjones: For PIE it is an ongoing cost 18:19:20 <mitr> pjones: Some of the numbers halfie got were that "PIE" builds are actually faster 18:19:24 <abadger1999> notting: ie: it would also take longer for an attacker to generate an exploit that relied on finding out addresses. 18:19:34 <pjones> mitr: right, and we still don't really know why. 18:19:38 <mitr> pjones: yes 18:19:41 <pjones> okay, I think I've got this mostly swapped in again now. 18:19:43 * nirik nods. 18:19:53 <t8m> mitr, pjones, it is probably within the error of the measurement 18:20:03 <halfie> mitr, I would ignore those numbers and assume that PIE performance <= non-PIE. 18:20:40 <pjones> t8m: does seem like it's merely hysteresis or something, yeah. 18:20:51 <mitr> halfie: Well, it does kind of make the other numbers questionable... However at this point I'm really not looking for a specific % theshold in the decision 18:21:30 <notting> the shorthand of performance would be, "all code performs as PIC code, not just linked in library code" 18:21:47 <notting> don't think there's a performance cost other than that? 18:22:14 <halfie> mitr, if you run the benchmarks, you will find my numbers accurate enough. Still I would like to go ahead with the assumption that PIE performance <= no-PIE performance. 18:22:41 <mitr> notting: Depends on the particulars of the proposal (whether -z now is added as well) 18:23:18 <t8m> Let's summarize: 1. PIE is about 3-4% slower than non-pie code in binary 2. this change does not affect code in shared libraries 3. PIE disables prelink slowing startup of libreoffice (for smaller apps the startup time difference is negligible) 4. PIE security benefits are not so important 5. we would still allow opt out of PIE if we change the default 18:23:29 <halfie> "I'd reiterate that the advantages of address space randomization on x86-64 are grossly exaggerated" <=== I don't agree with this. On 32-bit Fedora, stack address has 11 bits of entropy which is trivial to brute-force. You can't use such plain brute-force attacks against 64-bit ASLR. 18:23:47 <halfie> t8m, 1. only for some applications (not generally!) 18:24:08 <nirik> 1 is only for 1 application in an old paper no? 18:24:28 <t8m> halfie, that's because many applications have the computationally demanding code in shared libaries 18:24:51 <mitr> nirik: It was on the SPECcpu benchmark set IIRC, which is a reasonably large pile of code (IIRC including a version of gcc :)) 18:24:55 <pjones> t8m: right, shared libs are already pic, so they've already got this hit 18:25:39 <t8m> mitr, except it is a special code in the sense that it is in binaries and not in libraries as most of the code is :) 18:25:42 <nirik> and not our compiler flags. :) 18:26:10 <mitr> (http://www.spec.org/cpu2006/Docs/ "Benachmark Documentation") 18:26:26 <t8m> just from my workstation: du -s /usr/bin/ 18:26:26 <t8m> 410028 /usr/bin/ 18:26:37 <t8m> du -s /usr/lib64 18:26:42 <t8m> 1803100 /usr/lib64 18:26:48 <halfie> t8m, right, and this difference is only visible for 100% CPU bound apps 18:26:50 <halfie> I disagree with point 4. "PIE security benefits are not so important" 18:26:54 <halfie> can you explain why is this? 18:26:57 <halfie> On 32-bit Fedora, stack address has 11 bits of entropy which is trivial to brute-force. You can't use such plain brute-force attacks against 64-bit ASLR 18:27:04 <halfie> No-one has been able to mount *pure* brute-force attacks against 64-bit ASLR. (assuming there are no address leakage problems). 18:27:14 <pjones> t8m: so your point is it'll effect roughly 1/5 of the code we execute? 18:27:16 <t8m> halfie, there are various techniques how to overcome the randomization 18:27:23 <notting> t8m: includes a bunch of junk in subdirs. 18:27:29 <t8m> pjones, yep 18:27:49 <halfie> t8m, citation required. can you show me a real working exploit which bypasses / overcomes 64-bit ASLR with a remote attack? 18:27:51 <notting> t8m: /usr/lib64/*.so.* is ~680MB 18:29:09 <t8m> halfie, it depends on the type of bug, type of the server - for example on forking servers it is very much possible because after the fork the address space is always the same so you can try multiple times 18:30:32 <halfie> t8m, and yes, ASLR can't solve the problem itself. we need something like grsecurity's feature to detect such crashes caused by brute-force attempts. 18:30:56 <halfie> ^^ it is almost trivial to implement such crash and alert systems. 18:31:30 <jwb> no 18:31:39 <t8m> I think we can vote just now on the proposal given that we can always vote again if this does not pass and we get more compelling reasons. 18:32:00 <bress> t8m: Your argument sounds like "it's not 100% so let's not bother trying". PIE already covers a bunch of forking servers. It would help ensure attacking Linux is more work than it's worth. 18:32:00 <mitr> "We need to stop using C"</impractical> BTW note that most non-C languages are not impacted (at least Python, Perl and Ruby already have the core of the language in a shared library) 18:32:42 <halfie> mitr, good point. 18:32:50 <bress> mitr: Very little is impacted, I'd bet 80% of the distribution code is in shared libraries. 18:32:53 <t8m> bress, note that I'm for changing the default, playing devil's advocate 18:32:54 <bress> Maybe even more. 18:33:14 <bress> t8m: Understood. I missed some scrollback, I thought your position was unlike you ;) 18:33:40 <bress> On that note, all important servers are already covered. 18:33:51 <bress> This change is really to catch the desktopy stuff. 18:33:54 <mitr> bress: The numbers we have are a roughly equal split between *bin and *lib (but obviously unweighted by frequency of usage) 18:33:58 <pjones> bress: Yes, we know. 18:34:00 <halfie> t8m, http://www.vnsecurity.net/2012/02/exploiting-sudo-format-string-vunerability/ .. these guys had very hard time with local exploitation. Imagine if they were faced against 64-bit ASLR remotely. 18:34:44 <bress> mitr: Fair enough then. I did make that up :) 18:35:02 <nirik> would it be possible to run the specYYYY benchmark with fedora default flags then again with PIE and get some kind of approx performance change? 18:35:16 <t8m> mitr, given that shared libraries are expected to be shared, they are probably used more than the binaries :D 18:35:39 <bress> nirik: I don't think anyone has spec access. It's quite expensive IIRC. 18:35:45 <nirik> ah, bummer. 18:35:54 <t8m> nirik, and if that gives 2.9% or 4.8% instead of 3.6% does it change anything? 18:35:59 * nirik didn't know that was the case. do we have some other useful thing. 18:36:18 <bress> nirik: halfie did some benchmarks. 18:36:22 <nirik> t8m: it might. if it was 1.0 or 10% would it? 18:36:26 <bress> They were unexciting. 18:36:34 <notting> bress: using different flags than what we use, yes. 18:36:37 <halfie> nirik, lot of my benchmarks overlap with SPEC. 18:36:42 <abadger1999> t8m: if you were making a point that it's somewhat irrelevant... I tend to agree... real world code that we're running in Fedora is more important. 18:37:04 <halfie> nirik, if you are interested you can checkout https://github.com/kholia/unSPEC 18:37:11 <bress> nirik: Besides, somethign like spec is heavily CPU intensive, if something needs CPU performance, turn off PIE (things like video encoders could benefit here). 18:37:18 <nirik> the spec2006 thing is from 2012 with not our flags, etc. 18:37:21 <t8m> abadger1999, first I don't expect it to be 1 or 10% and second yes, real world code is more important 18:37:39 <t8m> bress, video encoders are already PIC in shared libraries 18:37:48 <bress> In which case PIE is free. 18:38:17 <bress> t8m: I suppose, I can't think of anything that doesn't use encoders in libraries. 18:38:53 <halfie> t8m, exactly, and same applies to audio audio encoding apps. there is no difference in peformance. I expected PIE builds to take a heavy beating but it didn't happen (do to all code being in the libs) 18:39:45 <bress> So out of curiosity, is anyone actually against this proposal? 18:40:00 <bress> It would also be a big PR event for Fedora. 18:40:17 <mitr> bress: I don't like the anti-prelink side effect (though I'm not sure whether that makes me a -0.5 or +0.5 ... ) 18:40:22 <halfie> there is one class of applications (chess engines) which are "real-world" apps and where there is a slowdown of <3.0%. I am very OK with putting such apps in a whitelist. 18:40:22 <nirik> I wouldn't say I am against it so much as reluctant to approve it over jakubs objections. I think he's smart and usually knows what he's talking about. 18:40:44 <notting> (real world encoders don't use the codecs in fedora anyway. ahem) 18:40:45 <mmaslano> nirik: I agree with you 18:40:58 <bress> mitr: Yeah, the loss of prelink could be a downside, but I also expect the things that benefit from prelink, we want to protect with PIE. 18:41:01 <nirik> would it be productive for you to talk with him directly and see if you can convince each other? or is that likely to be a bad idea? :) 18:41:04 <abadger1999> bress: with the current information and since the proposal allows maintainers to opt out, I'd be for the proposal. 18:41:26 <t8m> #proposal Make the _hardened_build default to 1 and allow it to be switched off for performance sensitive applications. 18:41:34 <bress> Is jakub against PIE, or for prelink? I've not talked with him. 18:41:43 <t8m> bress, against PIE 18:41:44 * notting is -1. would prefer consensus with tools maintainers. 18:41:47 <mitr> bress: For desktop applications that users have to manually start, PIE + prelink (== addresses change every 14 days) is perfectly appropriate I think 18:42:00 <abadger1999> bress: https://fedorahosted.org/fesco/ticket/1113#comment:10 18:42:01 <mmaslano> -1 18:42:04 <sgallagh> I'm still not convinced that the benefits outweight the costs here. I'm -1 18:42:07 <abadger1999> +1 18:42:09 <t8m> +1 18:42:17 <kseifried> +1 18:42:24 <halfie> halfie, +1 18:42:46 <abadger1999> kseifried: heh, sorry -- only fesco members get a counted vote for an actual proposal. 18:42:48 <notting> wait, fesco counts votes from everyone now? 18:42:49 * nirik notes this is a fesco vote. ;) 18:42:50 <t8m> kseifried, halfie, unfortunately your votes do not count :) 18:42:53 <jwb> notting, no 18:42:57 <jwb> -1 18:43:02 <sgallagh> Given that we already have an easy opt-in, I think forcing it is unnecessarily polarizing. 18:43:22 <nirik> so thats -4 +3 ? 18:43:30 <LinuxCode> good decision, for now 18:43:36 <kseifried> sgallagh, : one note: security options that are opt in don't get traction/acceptance/work. if people cared about security we wouldn't need PIE to begin with :P 18:43:47 <sgallagh> kseifried: Believe me, I understand that. 18:43:47 <t8m> kseifried, yep 18:43:48 * mitr will go with "0", still not sure how to weigh it 18:44:04 <sgallagh> That said, I opted in to PIE on SSSD, so it *does* sometimes gain traction :) 18:44:08 <mitr> kseifried: halfie Has already done quite a lot of work to ensure the important packages are PIE 18:44:12 <kseifried> also has anyone reported problems with the apps that currently have PIE enabled? 18:44:26 * pjones is also -1, preferring that the people making the tools didn't recommend against using them this way 18:44:26 <t8m> #info proposal is rejected (+3 -4 0:1) 18:44:31 <t8m> #undo 18:44:31 <zodbot> Removing item from minutes: <MeetBot.items.Info object at 0x38b78e90> 18:44:34 * nirik is also 0 18:44:43 <t8m> #info proposal is rejected (+3 -5 0:2) 18:44:53 <sgallagh> How do we have 10 votes? 18:44:53 <t8m> #undo 18:44:53 <zodbot> Removing item from minutes: <MeetBot.items.Info object at 0x38b78910> 18:45:03 <nirik> yeah, I might have miscounted. 18:45:03 <t8m> #info proposal is rejected (+2 -5 0:2) 18:45:36 <abadger1999> kseifried: I think that postgresql (tom lane) had some problems. but I could be misremembering the flags he was trying to add. 18:45:41 <notting> i do encourage halfie, kseifried, bress at all to work with the compiler & toolchain folks on a new proposal 18:45:48 <t8m> notting, +1 18:45:53 <halfie> notting, thanks, will do 18:45:53 <mitr> notting++ 18:45:56 <bress> This comment from Jakub makes it sound like we need to fix some PIE bugs. I trust jakub, we need to understand what's happening here. 18:46:05 <nirik> yeah, agreed. 18:46:15 <nirik> if those issues can be worked out it would be lovely. 18:46:17 <t8m> bress, I am afraid it won't be possible due to ABI 18:46:25 <notting> um, 'et. al.', not 'at all'. not sure how i managed to self-damnautocorrect 18:46:38 <t8m> let's go on 18:46:51 <t8m> #topic #1117 Generalize policy about privilege escalation and Administrator user accounts 18:46:52 <bress> t8m: Suggesting something is impossible is unwise ;) 18:47:01 <bress> Thanks for taking up the issue guys, I appreciate it. 18:47:05 <t8m> bress, impossible without breaking ABI 18:47:45 <t8m> .fesco 1117 18:47:46 <zodbot> t8m: #1117 (Generalize policy about privilege escalation and Administrator user accounts) – FESCo - https://fedorahosted.org/fesco/ticket/1117 18:48:10 <notting> unless i missed something, no proposal yet. table until there is one? 18:48:23 <jwb> please 18:48:27 <abadger1999> yep -- did someone offer to write aproposal? 18:48:29 <t8m> notting, yep, I should have probably cleared the meeting flag 18:49:05 <t8m> #info no proposal yet 18:49:24 <abadger1999> We could also close the ticket if no one is willing to take charge of this. 18:50:16 <t8m> perhaps but I'd leave it open for a while 18:51:05 <t8m> We don't have anything else on agenda. 18:51:16 <t8m> #topic Next week's chair 18:51:19 <abadger1999> okay -- it's just -- we're all here. If none of us is volunteering, it's not magically going to get written :-) 18:51:46 <t8m> #undo 18:51:46 <zodbot> Removing item from minutes: <MeetBot.items.Topic object at 0x38b78490> 18:52:13 <t8m> #info Anybody is encouraged to create a concrete proposal for generalizing the policy 18:52:14 <sgallagh> abadger1999: Perhaps that should be flagged as a discussion topic at Flock? 18:52:19 <sgallagh> We don't need it sooner than that. 18:52:33 <bress> I'm interested in helping with this policy FWIW. 18:52:46 <bress> (feel free to tell me to shut up and go away if I'm out of line) 18:52:51 <t8m> yep, it does not have to be a FESCo member 18:52:55 <abadger1999> bress: You are quite welcome to :-) 18:53:11 <sgallagh> bress: That would be fantastic. 18:53:14 <nirik> please do 18:54:13 <bress> Anytime you guys have security related thigns like this, feel free to send them my way. 18:54:13 <t8m> #topic Next week's chair 18:54:48 <t8m> Anybody volunteers? 18:55:16 <mitr> I can do that 18:56:12 <sgallagh> I may or may not be around next week. It's going to be a busy week at $DAYJOB 18:56:38 * mmaslano too 18:57:55 <t8m> I'm sorry I'm having internet connection outage just now... 18:58:37 <t8m> #action mitr to chair FESCo next week 18:59:02 <nirik> t8m: would you like someone else to finish out the meeting? or you back on line ok now? 19:00:14 <t8m> #topic Open Floor 19:00:14 <t8m> Still some packets get through :) 19:00:52 <nirik> I wanted to note https://bugzilla.redhat.com/show_bug.cgi?id=967385 to fesco folks. It wasn't referred to us (yet), but if anyone has strong opinions or would like it on the agenda down the road... 19:01:23 <jwb> do you have a tldr summary? 19:02:25 <nirik> livecd-tools used to remove root password (no password, anyone can su). this was fixed and the default is now 'locked'. 19:02:44 <nirik> however, our live media removes the password/lock in kickstart, so we have the same behavior as in the past. 19:02:53 <sgallagh> Right, as I recall that was the outcome of a CVE 19:02:54 <nirik> it's debatable if this is a security problem or not. 19:03:17 <mitr> If there is a "liveuser" with no password and full sudo root access, there's no security difference, is there? 19:03:19 <nirik> it does seem to break kdesu tho to have a locked root account. 19:03:51 <nirik> mitr: another step/single point people would need to go thru... so it's a slight difference, but dunno if it's worth it. 19:03:56 <notting> mitr: sudo instead of su breaks kde stuff 19:04:08 <kseifried> one note on this: when you do the "install to disk" option it won;t let you finish until you deal with the root password in the GUI Installer, so that's good 19:04:11 <sgallagh> mitr: Well, we could theoretically randomly-generate liveuser with an arbitrary suffix, which would prevent automated remote attacks, I guess 19:04:22 <mitr> sgallagh: Might just as well ask for a password then 19:04:30 <kseifried> and another note: locking the root account is a pretty standard configuration and should be supported without breaking things 19:04:31 <mitr> kseifried: that's an important point 19:04:32 <nirik> yeah, this only affects the live media running live. not installs. 19:04:45 <kseifried> mitr, : yeah, I checked cause I was worried it might do something bad =) 19:04:45 <sgallagh> mitr: Well, the user doesn't actually need to know the username on a live media, they're automatically logged in 19:05:17 <mitr> sgallagh: That's true for the user but not for the attacker we are presumably worried about? 19:05:28 <mitr> What attack vector is being considered here? 19:05:51 * nirik didn't mean for this to be a full topic, but ok. ;) 19:05:52 <kseifried> one note: any local access (e.g. crappy php app/any applictions/etc now means root access 19:05:57 <kseifried> which was probably not intended. 19:06:21 * mmaslano was told to chair rest of the meeting. t8m's internet is down 19:06:21 <mitr> (I suppose i'm just confused; for a live image that has no remote access and manual setup required for installation, I can't see that much reason to be concerned) 19:06:21 <nirik> get shell access on live media somehow, su -> root. vs get shell access on live media somehow -> su liveuser -> sudo -i root 19:06:28 <kseifried> giving the user account access to root is one thing for a live system but giving any application/running code root access was probably not the intention 19:06:46 <nirik> right. 19:07:43 <sgallagh> mitr: Well, I was forgetting that sshd is disabled by default on the live media. 19:07:46 <nirik> so, in any case doing any change for f19 seems crazy to me. ;) 19:07:51 <nirik> but something to look at for 20+ 19:08:04 <mitr> I think I agree with comment #19 19:08:08 <sgallagh> So I was on the wrong track 19:08:09 <kseifried> you guys should document this and warn people, as ANY running code can access root. web browser plugins, you name it. 19:08:37 <nirik> kseifried: they could also using sudo too no? 19:08:42 <t8m> I'm sorry I lost connection for a while 19:08:54 <mitr> kseifried: I can't see an obvious alternative for the live OS. "To start trying out Fedora, pick a secure password you probably won't need again?" 19:09:07 <mmaslano> t8m: https://bugzilla.redhat.com/show_bug.cgi?id=967385 19:09:16 <sgallagh> t8m: http://www.fpaste.org/15302/54548136/ 19:09:17 <kseifried> mitr: sudo: access all, no passwd for the liveuser account 19:09:30 <t8m> sgallagh, mmaslano, thanks 19:09:40 <mitr> kseifried: I'm afraid I don't understand. 19:09:42 <kseifried> mitr: or else make sure you document that any running code has root access cause I bet people weren't expecting that. 19:09:47 <kseifried> mitr: the root password is blank. 19:09:52 <kseifried> so any code can simply "su -" 19:09:55 <mitr> kseifried: So is liveusers' password. 19:10:32 <nirik> so currently anycode could also 'sudo -i' 19:12:15 <kseifried> right. but what if the user runs a web application that isn't srun as liveuser? that web app now == root. 19:12:34 <mitr> That was true before as well (httpd -> liveuser -> root) 19:12:41 <kseifried> like I said, if this is intentional you need to document this 19:12:56 <mitr> Documenting this is worth looking into, yes. 19:12:57 <nirik> kseifried: right, or we need to figure out a better way to setup the live media 19:13:14 <kseifried> yup. 19:13:23 <kseifried> or both 19:13:33 <sgallagh> kseifried: Sandboxed X session? 19:13:37 <mitr> t8m: Something worth considering - restrict su/sudo/login/etc. usage from system service accounts 19:13:52 <kseifried> or lock it down using pam to consoles/etc 19:13:57 <kseifried> interactive, etc. 19:14:12 <kseifried> but there are definitely better ways to handle it rather than simply having a blank root password 19:14:16 <t8m> kseifried, that would be too limiting 19:14:29 <kseifried> t8m, : what specifically would be to limiting? 19:14:29 <t8m> but mitr's proposal might be doable 19:15:03 * nirik thinks this is a good discussion to have, but perhaps on list? or outside meeting? I don't think we need to solve this here now. 19:15:03 <t8m> kseifried, you couldn't for example run ssh user@somewhere su - 19:15:14 <t8m> nirik, +1 19:15:27 <t8m> we definitely won't solve this here 19:15:32 <kseifried> t8m, : sorry, not tracking you 19:15:36 <mitr> nirik: right 19:16:48 <t8m> Anything else for Open Floor? 19:17:30 <sgallagh> I'd like to go on record with a Congratulations! to everyone that helped in getting Fedora 19 Beta out the door without slippage. 19:17:35 <sgallagh> Fantastic achievement folks1 19:17:49 <t8m> sgallagh, +1 19:18:21 <nirik> yes indeed. :) 19:19:52 <abadger1999> huzzah! :-) 19:20:28 <t8m> I will close the meeting in a minute if we do not have anything else to discuss. 19:21:26 <t8m> #endmeeting -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
