===================================
#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-...
.
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-vunerabil... .. 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