User: Password:
Subscribe / Log in / New account

Fedora to (try to) remove setuid files for F15

From:  Kevin Fenzi <>
Subject:  Summary/Minutes from today's FESCo meeting (2010-10-26) NEW TIME!
Date:  Wed, 27 Oct 2010 13:41:06 -0600
Message-ID:  <>
Archive-link:  Article

#fedora-meeting: FESCO (2010-10-27)

Meeting started by nirik at 18:30:00 UTC. The full logs are available at

Meeting summary
* init process  (nirik, 18:30:01)

* Updates policy / Vision implementation status  (nirik, 18:36:20)
  * LINK:   (nirik,
  * LINK:
    (cwickert, 18:46:52)
  * LINK:
    (cwickert, 18:46:52)
  * LINK:
    (cwickert, 18:46:52)
  * LINK:
    (cwickert, 18:46:59)
  * LINK:
    (cwickert, 18:46:59)
  * LINK:
    (cwickert, 18:47:05)
  * LINK:
    is different from
    (cwickert, 18:51:02)
  * ACTION: cwickert will work on new features repo ideas  (nirik,
  * ACTION: SMParrish will work on metrics  (nirik, 19:00:59)

* #416 Set EOL Date For Fedora 12  (nirik, 19:01:03)
  * AGREED: F12 eol will be 2010-12-02, moving forward eol dates will be
    the nearest weekday to 1 month from release  (nirik, 19:07:33)

* Elections coming up.  (nirik, 19:08:21)
  * LINK:
    (nirik, 19:10:16)

* Kudos for F14 release  (nirik, 19:10:39)

* #480 F15Feature - RemoveSETUID ( )  (nirik,
  * AGREED: the feature is approved.  (nirik, 19:26:46)

* Open Floor  (nirik, 19:26:50)
  * LINK:   (abadger1999,

* break build inheritance between F14 and F15 and update deltarpm files
  (nirik, 19:27:56)
  * AGREED: Fesco is fine with the indicated plan of mass tagging,
    breaking inherit, and scrubbing old deltarpms for rawhide.  (nirik,

* Open Floor  (nirik, 19:36:53)

Meeting ended at 19:39:44 UTC.

Action Items
* cwickert will work on new features repo ideas
* SMParrish will work on metrics

Action Items, by person
* cwickert
  * cwickert will work on new features repo ideas
* SMParrish
  * SMParrish will work on metrics
  * (none)

People Present (lines said)
* nirik (115)
* cwickert (51)
* pjones (29)
* ajax (24)
* abadger1999 (17)
* notting (16)
* mclasen (14)
* mjg59 (14)
* zodbot (9)
* kylem (9)
* SMParrish (6)
* wwoods (6)
* Southern_Gentlem (3)
* adamw (1)
* rbergeron (1)
18:30:00 <nirik> #startmeeting FESCO (2010-10-27)
18:30:00 <zodbot> Meeting started Wed Oct 27 18:30:00 2010 UTC.  The chair is nirik. Information
about MeetBot at
18:30:00 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
18:30:01 <nirik> #meetingname fesco
18:30:01 <nirik> #chair mclasen notting nirik SMParrish kylem ajax pjones cwickert mjg59
18:30:01 <nirik> #topic init process
18:30:01 <zodbot> The meeting name has been set to 'fesco'
18:30:01 <zodbot> Current chairs: SMParrish ajax cwickert kylem mclasen mjg59 nirik notting pjones
18:30:37 <pjones> yo.
18:30:39 <nirik> who all is around for meeting?
18:32:04 <pjones> just me and you I guess.
18:32:06 * notting is here
18:32:06 * nirik wonders if we have quorum today.
18:32:08 <pjones> ;)
18:32:10 <kylem> yo.
18:32:31 <pjones> mjg59 was around a few minutes ago.
18:34:11 * nirik waits a few to see if we get one more person for quorum
18:35:28 <mjg59> pjones: Hi
18:35:35 <mjg59> Sorry, briefly distracted
18:35:50 <nirik> cool. I think we can go ahead and get started.
18:36:01 <cwickert> am I late?
18:36:06 <nirik> cwickert: nope, just in time. ;)
18:36:09 <cwickert> ;)
18:36:13 <mjg59> cwickert: Fashionably so
18:36:20 <nirik> #topic Updates policy / Vision implementation status
18:36:20 <nirik> .fesco 351
18:36:20 <nirik> .fesco 382
18:36:22 <zodbot> nirik: #351 (Create a policy for updates) - FESCo - Trac -
18:36:26 <zodbot> nirik: #382 (Implementing Stable Release Vision) - FESCo - Trac -
18:36:31 <nirik> SMParrish was going to look at more stats stuff.
18:36:38 <nirik> Also, I talked with lmacken about bodhi stats.
18:37:08 <nirik> He was going to generate them for us so we could see what was in them, and also
try and do a 'pre release' 'post release' split for f14
18:37:32 <nirik> the next bodhi version will allow (I think) running them from cron/regularly.
18:38:21 <nirik> It seems like we are not making much progress to finishing this up. Anyone have
ideas on how we could finish things before next elections?
18:38:32 * SMParrish sorry I'm late.
18:39:01 <SMParrish> nirik: was travelling last week. just got home yesterday and have not had time
to work on the metrics issue
18:39:14 <nirik> ok.
18:39:18 <cwickert> I think we still suffer from unclear board statements
18:39:33 <pjones> cwickert: I think we're always going to suffer from that
18:39:52 <pjones> we should just interpret them as best we can and if that's really something they
didn't want then we do it again :/
18:39:55 <cwickert> I was talking to some board members and they were not happy with the "only
security and bugfixes" thing ether
18:40:42 <notting> and...? internal board politics are a matter for the board.
18:41:19 <mjg59> The board's statement explicitly says " Stable releases should provide a
consistent user experience throughout the lifecycle, and only fix bugs and security issues. "
18:41:22 <nirik> I'd really like to see us try the current policy for a bit. It may be too
conservative, but we can adjust it if so down the road.
18:41:42 <nirik> we also were going to look into a 'new features' repo.
18:42:46 <nirik> perhaps we could set action items and people on the remaining tasks?
18:42:58 <nirik> SMParrish: work with lmacken on metrics ?
18:43:08 <cwickert> speaking of that, I was supposed to write a propsal on the new-features repo
18:43:19 <nirik> cwickert: yeah.
18:43:24 <kylem> i think this is mostly just a reflection fo the project as a whole, looking at
#fedora-dveel you'd be hard pressed to find unilateral agreement on the interpretation of our
18:43:58 <SMParrish> nirik: yes i will get with lmacken on the metrics issue
18:44:02 <pjones> nirik: yeah, I'm with you in that we need more observation to see what we've
18:44:03 <cwickert> i have two problems: it is hard to find the status quo as there are a lot of
outdated update-something pages in the wiki now
18:44:25 <nirik> we should nuke or redirect the old ones to the current one.
18:44:30 <pjones> yep
18:44:40 <cwickert> the second problem is: two weeks ago a lot of questions were raised in the
18:44:48 <cwickert> but they have not made it into the wiki
18:45:13 <nirik> questions on the new feature repo? or ?
18:45:19 <cwickert> ys
18:45:21 <cwickert> yes
18:45:33 <cwickert> how things work in bodhi and all that
18:45:46 <cwickert> but they are not on
18:46:00 <cwickert> I guess I'll have to dig in the meeting logs
18:46:00 <nirik>
18:46:25 <nirik> that should be the page maintainers look at/follow.
18:46:51 <cwickert> there is a few more
18:46:52 <cwickert>
18:46:52 <cwickert>
18:46:52 <cwickert>
18:46:59 <cwickert>
18:46:59 <cwickert>
18:47:05 <cwickert>
18:47:15 <nirik> the last one is the vision from the board.
18:47:34 <notting> anything in the User: namespace should obviously not be policy
18:47:37 <pjones> seems like we should make a category template for the various User: Proposal:
ones and tag them so it says something at the top of the page or something.
18:47:37 <nirik> the rest should be removed probibly. (Although we do still have things to
implement from the implementation_ideas page)
18:47:52 <pjones> (not that I've got any idea how to do that on the wiki)
18:48:21 <cwickert> the problem is there are conflictins statements
18:48:22 <abadger1999> pjones: Could just use {{draft}}
18:48:35 <pjones> nirik: I'm not sure I'm okay with us deciding to remove stuff under User: (unless
it violates various codes of behavior of course)
18:48:38 <pjones> abadger1999: yeah
18:48:48 <abadger1999> pjones: Although you might want something that also says "rejected" or
"alternative was implemented"
18:48:51 <pjones> abadger1999: I was thinking something a little stronger than that, but that's
certainly the right idea.
18:48:52 <nirik> pjones: true. Althought we could add a 'note: this is NOT policy' or something.
18:49:22 <cwickert> e.g. the last paragraph of is not exactly what says
18:49:37 <pjones> nirik: yeah, something like {draft} but maybe a little more "don't use this as
reference" since lots of people are used to reading draft documents as the canonical source for
data ;)
18:50:03 <nirik> cwickert: about exceptions?
18:50:15 <cwickert> nirik, about criteria
18:50:33 * nirik is not following.
18:50:56 <nirik> The critical path / other updates sections?
18:51:02 <cwickert> is different
18:51:12 <cwickert> at least slightly
18:51:47 <cwickert> the information should be one one single page to make sure we have no
contradictions and no redundancy
18:51:48 <nirik> well, I thought I copied it from the one page to the new one.
18:52:12 <nirik> yes, I copied Package_update_acceptance_criteria data into Updates_Policy
18:52:17 <nirik> where I messed up we should fix it.
18:52:38 <cwickert> ok, what else is left to do except a clean-up?
18:53:10 <cwickert> i guess
18:53:21 <nirik> if you see issues that are obviously me messing up the copy, just fix them. If
it's something that should be changed, bring it up here and we can vote on it.
18:53:28 <nirik> right, we need:
18:53:31 <cwickert> i hope I can come up with a proposal for the next meeting, I'm just too busy in
my dayjob
18:53:33 <nirik> metrics: how well is this working
18:53:44 <nirik> new feature repo: if it's fesable
18:53:47 <cwickert> what kind of metrics would that be?
18:54:26 <cwickert> i mean, how to judge if something is working? can we count how many people are
cheating in bodhi?
18:54:37 <nirik> anything we could gather that would apply to: "Project members should be able to
transparently measure or monitor a new updates process to objectively measure its effectiveness,
and determine whether the updates process is achieving the aforementioned vision statements"
18:55:23 <nirik> we can count numbers of updates, numbers of bodhi comments/tests, number of karma
submitters, number of bugs, etc.
18:55:49 <cwickert> so? what do we gain when counting the number of comments in bodhi?
18:56:05 <nirik> an increase in testing?
18:56:07 <cwickert> if even rel-eng gives "proxy karma" without testing
18:56:23 * nirik is happy to listen to any other metrics you think we should gather.
18:56:50 <cwickert> I'm sorry, I don't have any
18:57:07 <cwickert> but what I see at makes me think we are not doing
more testing than before
18:57:17 <wwoods> you're wrong.
18:57:20 <wwoods> provably so.
18:57:21 <cwickert> just an example, I'm sure there are plenty of this
18:57:33 <wwoods> that is an anecdote; the data say otherwise.
18:57:35 <nirik> the plural of anecdote is not data.
18:57:52 <nirik> anyhow, lets see what SMParrish comes up with and go from there?
18:58:05 <cwickert> wwoods, if two out of three testers are faking results, what have we gained?
18:58:17 <mjg59> One tester
18:58:25 <wwoods> furthermore, if that were actually correct - what would be the correct solution?
Do *less* testing?
18:58:28 <cwickert> well...
18:58:34 * nirik notes we are over 15min on this topic.
18:59:11 <cwickert> wwoods, not have technical limitations that make people abuse the guidelines.
18:59:29 <wwoods> finding problems with a process should probably cause you to look for ways to
improve the process
18:59:32 <cwickert> anyway, I'm happy for all numbers we can gather, but I doubt they are
19:00:00 <nirik> ok, anything further on updates? or shall we move on?
19:00:01 <wwoods> so - constructive suggestions on that topic would be excellent! probably not here
and now, though.
19:00:09 <cwickert> +1
19:00:51 <nirik> #action cwickert will work on new features repo ideas
19:00:59 <nirik> #action SMParrish will work on metrics
19:01:03 <nirik> #topic #416 Set EOL Date For Fedora 12
19:01:03 <nirik> .fesco 416
19:01:08 <zodbot> nirik: #416 (Set EOL Date For Fedora 12) - FESCo - Trac -
19:01:11 <cwickert> can we also have somebody to clean up the wiki?
19:01:15 <nirik> Since F14 was pushed out a week, should we move EOL for F12 as well?
19:01:27 <nirik> cwickert: I can try, but I also have been very busy.
19:01:38 <pjones> nirik: yeah, we should keep them in lock-step I guess.
19:01:45 <cwickert> +1
19:02:12 <ajax> sure, why not
19:02:14 <mjg59> nirik: +1
19:02:29 <nirik> ok, +1 from me too.
19:02:36 <Southern_Gentlem> suggest 12/1/2010
19:02:44 <nirik> Further on this topic, instead of us voting on it, do we want to just setup a
general rule?
19:02:50 <pjones> nirik: yes
19:02:57 <nirik> ie, nearest weekday to 1 month from release.
19:03:00 <notting> ACK
19:03:04 <pjones> +1
19:03:07 <mjg59> +1
19:03:12 * mclasen is all for auto-EOL
19:03:13 <mclasen> +1
19:03:17 <ajax> +1
19:03:25 <nirik> that would make it 2010-12-02 for this case tho (2010-12-03 was suggested)
19:03:58 * notting is +1 to lockstep, +1 to auto-lockstep
19:04:20 <pjones> nirik: nearest to or first after?
19:04:31 <kylem> +1.
19:04:32 <nirik> pjones: we could do that I suppose.
19:04:41 <pjones> not that I really care.
19:04:41 * nirik doesn't feel too strongly either way.
19:05:22 <nirik> anyone object to 'nearest weekday 1 month from release +1 day' ?
19:05:37 <ajax> fine with me
19:05:50 <cwickert> same here
19:05:56 <Southern_Gentlem> why the +1 day?
19:06:11 <kylem> latency.
19:06:12 <kylem> :P
19:06:24 <nirik> I guess that just makes it more complex.
19:06:42 <nirik> so, lets just do nearest weekday to 1 month after release.
19:07:07 <pjones> I'm thinking "first weekday after" just because that means we prefer mondays to
19:07:18 <pjones> (well, on or after.  gah.)
19:07:27 <ajax> also fine with me.
19:07:33 <nirik> #agreed F12 eol will be 2010-12-02, moving forward eol dates will be the nearest
weekday to 1 month from release
19:07:42 <nirik> pjones: I don't know that it matters...
19:07:59 <pjones> fair enough.
19:08:19 <nirik> Some topics that are just announcements/notices:
19:08:21 <nirik> #topic Elections coming up.
19:08:31 <nirik> elections are starting up for board, fesco, famsco
19:09:18 <nirik> Everyone should vote. ;)
19:09:25 <kylem> lol
19:09:27 <pjones> +1
19:09:31 <ajax> early and often.
19:09:33 * nirik looks to see who is up from fesco...
19:09:44 <notting> ajax, cwickert, pjones, mjg59
19:09:45 <mjg59> Me, ajax, pjones, cwickert?
19:09:47 <mjg59> Yeah
19:09:52 <rbergeron> ...or nominate themselves for open positions :)
19:09:57 <nirik> Adam Jackson (ajax), Christoph Wickert (cwickert), Peter Jones (pjones), and
Matthew Garrett (mjg59)
19:10:10 * nirik thanks notting for updating the page.
19:10:16 <nirik>
19:10:32 <nirik> moving on...
19:10:39 <cwickert> I haven't seen an announcement on devel list
19:10:39 <nirik> #topic Kudos for F14 release
19:10:42 * Southern_Gentlem crosses fingers that they all reapply for the job
19:10:58 <nirik> cwickert: yeah, not sure who is coordinating this time. ;( will find out tho.
19:11:11 <notting> nirik: i think everyone's coordinating their own?
19:11:24 <notting> do we want to designate someone to post to the devel list?
19:11:31 <nirik> I'd like to thank all the maintainers, qa folks, users and rel-eng for making F14
such a smooth release. :)
19:11:37 <cwickert> +1
19:11:39 <nirik> notting: oh, usually there's a coordinator.
19:11:51 <cwickert> especially for QA, adamw does a great job
19:12:10 <nirik> seconded. ;)
19:12:27 * adamw would like to thank all the people who did all the work
19:12:57 <nirik> I can find out if there is a coordinator this time, and if not, at least mail the
devel-announce list about nominations being open.
19:13:14 <SMParrish> +1 kudos to all
19:13:20 <notting> nirik: wfm
19:13:22 <cwickert> nirik, there was something in the board list about coordination
19:13:24 <notting> nirik: thanks!
19:13:53 <nirik> ok, I had one f15 feature that I didn't note in time for the agenda. We could do
it now, or wait until next week?
19:14:51 <cwickert> how about now?
19:14:54 <mjg59> Sure
19:14:55 <abadger1999> pjones, cwickert: Re: a template like {{draft}} I just made this for ya'll:  Go ahead and change it if you want
something slightly different.
19:15:12 <nirik> abadger1999: thanks!
19:15:15 * abadger1999 sorry for jumping in with that but has to leave soon
19:15:16 <nirik> #topic #480 F15Feature - RemoveSETUID ( )
19:15:16 <nirik> .fesco 480
19:15:17 <zodbot> nirik: #480 (F15Feature - RemoveSETUID ( )) - FESCo - Trac -
19:15:36 <pjones> abadger1999: excellent.
19:15:57 * cwickert looks
19:16:15 <nirik> I'm +1 on this. I don't know how hard it's going to be, but if anyone can get it
to happen dwalsh can. ;)
19:16:39 <ajax> i'm only barely +1 to this since i still think capabilities are far too
coarse-grained to be of much use
19:16:46 <mjg59> I'm also +1, though concerned about the degree to which things may end up
19:17:01 <pjones> I'm +0 to this for the sam reason ajax is barely +1 to it.
19:17:02 <mjg59> I can't see it /reducing/ security, but I don't think it's as big a win as it
could be
19:17:22 <ajax> but f15's xserver is already shipping non-setuid, so, whatever.
19:17:50 <notting> ajax: sys_admin or raw_io?
19:18:01 <ajax> notting: both those and also dac_override
19:18:07 <mclasen> is the dependency list on the tracker bug complete ?
19:18:11 <mclasen> 24 sounds low...
19:18:29 <nirik> it does seem low yeah.
19:19:14 <notting> ajax: that doesn't remove much. if anything.
19:19:17 <ajax> notting: if that sounds like zero effective reduction in privileges, that's because
it's no effective reduction in privs.
19:19:22 <ajax> so, like i said.
19:19:38 <ajax> hey cool we can use capabilities!  if only that were meaningful!
19:19:50 <mclasen> would be good if the feature page had some advice on how to find out the
'correct caps' to use
19:19:56 <notting> i'm moderately for the idea, but it remains to see if we'll come up with
anything useful
19:20:17 <ajax> xserver might be a special case, but really anything that needs dac_override or
sys_admin is trivially equivalent to root
19:20:27 <pjones> mclasen: the problem is that the capabilities are so poorly thought out that
that's a non-trivial (and possibly non-meaningful) exercise.
19:20:41 <mclasen> and one that breaks at runtime if you get it wrong ?
19:20:48 <ajax> mclasen: indeed.
19:20:49 <pjones> yep.
19:21:41 <ajax> i would say i get the feeling the caps were designed by someone who had never tried
to root a machine, but that would imply that i thought they were designed period.
19:21:54 <mclasen> so we need individual testing attention for each binary that gets that
treatment, I guess
19:22:42 <ajax> yeah.  again, if dan wants to drive that, great.
19:22:58 <notting> ajax: 'designed by someone who only wanted to remove setuid from ping, other
things are an afterthought'?
19:23:34 <ajax> notting: that's a bit closer, yeah.
19:24:27 <ajax> anyway.  +1 to the feature even though it's of the most marginal utility.
19:25:04 <nirik> so where are we here...
19:25:11 <nirik> +3 I see
19:25:19 <cwickert> +1, see what it brings
19:25:31 <SMParrish> +1
19:26:13 <pjones> I guess I could be +1 despite limited utility.  It's not a bad thing to do per
19:26:46 <nirik> #agreed the feature is approved.
19:26:50 <nirik> #topic Open Floor
19:26:55 <nirik> Anything for open floor?
19:26:57 * mclasen adds comments to the feature page and gives a +1
19:27:00 <ajax> hah!  the bugs even cite Xorg as the example.
19:27:09 * ajax ahead of the curve
19:27:32 <abadger1999>
19:27:39 <nirik> ah yes,
19:27:56 <nirik> #topic break build inheritance between F14 and F15 and update deltarpm files
19:28:07 <nirik> .rel-eng 4224
19:28:09 <zodbot> nirik: Ticket #4230 (task created): build tag override request for
eclipse-3.6.1-2.fc14 || Ticket #4229 (task closed): Retire from F15 || Ticket
#4229 (task created): Retire from F15 || Ticket #4228 (task created): Buildroot
override request for libtorrent || Ticket #4227 (task created): tag request: dist-f14-override
for libgda-4.2.0-1.fc14 || Ticket #4226 (defect closed): (11 more messages)
19:28:15 <abadger1999> Oxf13: You around for this?
19:28:16 <nirik> oops. thats not right. ;)
19:28:34 <ajax> eesh, this looks vile.
19:29:15 <nirik> yes, yes it does.
19:29:36 <abadger1999> This comment is probably the best summary of the problem:
19:29:51 <abadger1999> The initial report has the proposed solution.
19:30:31 <nirik> given that it falls back to the full rpm ok and that deltas are only somewhat
usefull in rawhide anyhow...
19:30:32 <abadger1999> I think Oxf13 would like fesco input because we normally don't break build
inheritance by itself... although we do in practice if we do a mass rebuild 9but once again, that
would normally be later in the cycle)
19:30:42 <nirik> this is just f15 right?
19:30:48 <abadger1999> Correct.
19:30:55 * nirik whews
19:31:11 <abadger1999> It won't affect f14 as jnovy isn't going to push the new xz back.
19:31:19 <nirik> thank goodness.
19:31:32 <mclasen> whats the consequence of broken build inheritance ? people have to build their
stuff for rawhide ?
19:31:40 <mclasen> doesn't sound too onerous to me
19:31:55 <ajax> mclasen: yeah, f14 builds won't automatically bubble to f15.
19:31:56 <abadger1999> mclasen: Correct.  A build for F14 won't automatically go to F15.
19:32:11 <nirik> if we nuke existing deltas does that mean we would need a compose to rebuild them
all? (ie, a long ass one)
19:32:35 <abadger1999> nirik: No, the idea is that we'll only have deltas for packages built after
that time.
19:32:41 <nirik> ok, good.
19:32:45 <notting> rawhide deltas are just against the prior tree
19:32:55 <abadger1999> nirik: The reason is that the final package on the user's system will have
been built with the xz on the user's system.
19:33:07 <nirik> I'm fine with the plan then... tag, break inhert, nuke deltas, move on.
19:33:09 <abadger1999> nirik: And when the update package was old, that's what's causing the
19:34:02 <pjones> yeah, I'm fine with this plan.
19:34:14 <ajax> works for me
19:34:22 <SMParrish> based on that I'm good with it
19:34:40 <nirik> that's +4 I think.
19:34:43 <mclasen> +1
19:35:01 <kylem> hrm.
19:35:04 <mjg59> +1, I think
19:35:05 <kylem> +1.
19:35:12 <mjg59> I can't see anything obviouly better
19:35:16 <kylem> i'd like t think about it more though.
19:35:31 <nirik> #agreed Fesco is fine with the indicated plan of mass tagging, breaking inherit,
and scrubbing old deltarpms for rawhide.
19:35:34 <ajax> well, besides turning off deltas
19:35:52 <nirik> well, deltas are not usually that usefull in rawhide, unless you make sure to
update every single day.
19:36:27 <nirik> and even then, if you had an day out of date mirror, etc.
19:36:40 <abadger1999> Cool.
19:36:48 * abadger1999 has to vamoose now.
19:36:52 <ajax> yeah, i really don't see much benefit in drpms for rawhide
19:36:53 <nirik> #topic Open Floor
19:37:05 <nirik> any further open floor items? or shall we wrap up?
19:37:06 <mclasen> do we have a date for that event ?
19:37:33 <nirik> mclasen: I guess when rel-eng is ready... it should be announced, etc.
19:37:46 <mclasen> sure, sounds fine
19:37:54 * mclasen was just making sure its not happening tomorrow
19:38:40 <nirik> I think the new xz has landed, but the only harm right now is that deltarpms don't
19:39:10 * nirik will close out the meeting in a few here if nothing comes up.
19:39:13 <notting> right, and since they fallback, i wasn't thinking it was OMG critical
19:39:34 <nirik> yeah.
19:39:39 <nirik> ok, thanks for coming everyone!
19:39:44 <nirik> #endmeeting
devel mailing list

(Log in to post comments)

What about daemons?

Posted Oct 29, 2010 12:20 UTC (Fri) by bollin (subscriber, #5582) [Link]

Most daemons do not need root privileges to start. Having the right capabilities like CAP_NET_BIND_SERVICE for low ports is good enough. It would be a good idea to fix such things too.

What about daemons?

Posted Nov 8, 2010 7:03 UTC (Mon) by solardiz (subscriber, #35993) [Link]

In my opinion, it is an illusion that starting a daemon up with CAP_NET_BIND_SERVICE improves security vs. having it start as root, create a PID file, acquire the socket, maybe go into a chroot jail, and drop to a non-root user. The opposite is true: if we only grant this one capability, the daemon does not know to and is likely "not privileged" to drop the capability, so it retains it for its lifetime (thereby letting a possible intruder impersonate services on _other_ privileged ports as well). It is not able to chroot() itself. It has to write its PID file as the non-root user and in a directory writable by the user (or it has to rewrite a pre-created PID file in-place, which has its own issues) - and then what, our startup scripts access that file as root and trust the PID found in there, thereby risking a root compromise via hostile file metadata or contents? OK, the scripts may be taught to switch to the same pseudo-user before accessing the file and signaling the process, but that's extra complexity. My estimate/experience is that most packagers and sysadmins get it wrong, even without the capability complication. Yet with properly written daemons there's simply no reason to do things in that complicated way.

Use of capabilities by daemon processes themselves, after they were started as root, makes more sense to me - e.g., vsftpd and BIND 9 do that.

Fedora to (try to) remove setuid files for F15

Posted Oct 29, 2010 13:21 UTC (Fri) by nelhage (subscriber, #59579) [Link]

While I appreciate the effort, this seems unlikely to actually help much. There
will still be programs like 'sudo' and 'su' that need CAP_SETUID or similar
permissions that can probably be easily leveraged to gain full privileges. The
right solution is probably to kill both file capabilities and setuid, and to use
something like PolicyKit that sets security policy and grants privileges to
authorized processes, for instance by passing file descriptors over a local

Honestly, I question whether moving to file capabilities is even an improvement
-- attackers will probably find ways around this, and system administrators are
already familiar with and understand setuid. I don't even know offhand, for
instance, how to check which capabilities a file has.

Fedora to (try to) remove setuid files for F15

Posted Oct 29, 2010 13:22 UTC (Fri) by mattdm (subscriber, #18) [Link]

/usr/sbin/getcap, FWIW.

Fedora to (try to) remove setuid files for F15

Posted Oct 29, 2010 13:23 UTC (Fri) by mattdm (subscriber, #18) [Link]

And colorized ls makes them show up with a red background, similar to suid binaries.

Fedora to (try to) remove setuid files for F15

Posted Oct 29, 2010 14:06 UTC (Fri) by SEJeff (subscriber, #51588) [Link]

There are still administrators who couldn't figure out how to remove a file you set immutable with chattr +i to save their life. There are still lots of nix professionals who don't get {set,get}facl when it is actually very easy to learn. At least gnu ls shows these files in red when color mode is enabled or a + on the right hand side of the permissions line for facls. Plenty of people don't understand how to use or tweak their shiney Linux userland to the the max. As a Linux professional I would consider myself one that hasn't "learned it all".

That will never stop. However, this is a noteworthy goal. Preventing su / sudo is not the point. Preventing bugs in applications that think they need root and then perhaps drop privs _is th point_. To that end, it is a noble goal and one I look forward to seeing the results of.

Just like how SELinux prevents a lot of stock exploits and worms cold, this is another layer in the security bag-o-tricks.

Fedora to (try to) remove setuid files for F15

Posted Oct 30, 2010 21:00 UTC (Sat) by jcm (subscriber, #18262) [Link]

I'm more concerned that file capabilities work on all filesystems you might be using and that existing capability is preserved in the migration. I know that new things come along all the time, but I'm not in favor "change for the sake of change". I'm in favor of "change that fixes a real problem". In my mind, I think we have other bigger problems (like update policy).

Fedora to (try to) remove setuid files for F15

Posted Oct 30, 2010 21:18 UTC (Sat) by mjg59 (subscriber, #23239) [Link]

Update policy is entirely orthogonal to this. Why should we prevent people working on other things to make Fedora better just because we haven't finished the process of developing our update policy?

Fedora to (try to) remove setuid files for F15

Posted Oct 30, 2010 8:17 UTC (Sat) by marcH (subscriber, #57642) [Link]

> While I appreciate the effort, this seems unlikely to actually help much. There will still be programs like 'sudo' and 'su' that need CAP_SETUID or similar permissions that can probably be easily leveraged to gain full privileges.

See answer here:

Fedora to (try to) remove setuid files for F15

Posted Oct 31, 2010 12:18 UTC (Sun) by kevinm (guest, #69913) [Link]

As pointed out in the conversation, there are several capabilities that equivalent to being setuid root anyway:

19:20:17 <ajax> xserver might be a special case, but really anything that needs dac_override or sys_admin is trivially equivalent to root

Fedora to (try to) remove setuid files for F15

Posted Nov 8, 2010 7:07 UTC (Mon) by solardiz (subscriber, #35993) [Link]

For the curious, I dispute Fedora's plan in some detail and I suggest alternatives here:

Fedora to (try to) remove setuid files for F15

Posted Nov 8, 2010 7:24 UTC (Mon) by dlang (subscriber, #313) [Link]

disputing one point in your article.

one very good reason for having someone login as themselves and then su/sudo to root rather than just logging in as root is that it gives you some sort of idea who it was that became root (it's not perfect because someone may have walked away from an unlocked screen, but it's a whole lot better than 'anyone with a root password could have done this')

yes, you could create root equivalent accounts for everyone, but that's a lot of extra passwords and accounts to manage.

Fedora to (try to) remove setuid files for F15

Posted Nov 8, 2010 8:48 UTC (Mon) by solardiz (subscriber, #35993) [Link]

Thank you for the feedback. As you have noticed, I actually addressed the accountability issue by proposing multiple root accounts. That's an approach we (the sysadmin teams I'm on) use since late-1990s, and it's working very well - at least no worse than non-root accounts + su would in this respect.

No extra passwords and no extra accounts to manage. It would be a security risk for a sysadmin to share a non-root account for su'ing to root and for other uses (a lot of people do just that, but it's plain wrong to take the unjustified risk, in my opinion). Thus, there would have to be _two_ non-root accounts per person. With our approach, this is replaced with one root-privileged account and one non-root account. (Also, SSH keys are used instead of passwords in most cases. And it is OK to use the same keypair for root and non-root.)

Fedora to (try to) remove setuid files for F15

Posted Nov 8, 2010 8:56 UTC (Mon) by dlang (subscriber, #313) [Link]

we have different criteria for what's acceptable.

I don't see anything fundamentally wrong with using the same account to launch su and to do other things, and I see a major problem with using the same SSH keypair for different purposes.

Fedora to (try to) remove setuid files for F15

Posted Nov 8, 2010 9:25 UTC (Mon) by solardiz (subscriber, #35993) [Link]

It could be different criteria, but I've actually seen security compromises propagate from non-root to root due to use of su or sudo while also using the same non-root account for other purposes and/or logging in to it from more places.(*) I haven't seen any security compromises that I could attribute to SSH keypair reuse for root and non-root on the same target machine.

(*) I've also seen security compromises propagate from one server to another via scp/sftp/ssh invoked _from_ a server.

What specific major problem do you see with using the same SSH keypair for root and non-root on the same target system? I do see how using different keypairs - only with different and very strong private key passphrases - would potentially improve security a little bit if the "root keypair" is extremely rarely used. But that sounds like more of an exception than the typical case, especially when one has to co-administer many servers. There's simply no other sane choice than to accept some SSH keypair reuse. We typically opt to use one SSH keypair per person per target network or target project:

Fedora to (try to) remove setuid files for F15

Posted Nov 9, 2010 3:40 UTC (Tue) by cras (guest, #7000) [Link]

I'd think you can create a poor man's su/sudo by simply creating a new SSH key, adding it to root's allowed_keys and use "alias sudo ssh -i ~/.ssh/id_dsa.root root@localhost". sudo-style password remembering can be done by ssh-agent.

BTW. I like your way of getting rid of setuid binaries more. That's actually what I thought F15's plan was when I first read the headline, but then got disappointed.

Fedora to (try to) remove setuid files for F15

Posted Nov 17, 2010 4:39 UTC (Wed) by Baylink (guest, #755) [Link]

My snap reaction to this, and I'm certainly willing to be proven wrong, is that this pushes the decision about how to make a given program secure from the programmer, who a) knows the code intimately, and b) only has to do it once, out to either the various distribution managers (ca 100's), or the end system administrators (ca 1,000,000's), with decreasing levels of understanding of both the code, and the security process, and thereby logarithmically increasing levels of questionably protected attack surface...

IE: that's it's a thoroughly miserable idea from up here at 40,000ft, no matter how clever it looks at 5000ft.

Why am I wrong? :-)

Copyright © 2010, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds