[00:01] [minutes will be up shortly...] === mc44_ is now known as mc44 === ubottu changed the topic of #ubuntu-meeting to: Current meeting: Bugs for Hugs Day | Calendar: http://fridge.ubuntu.com/event | Logs: https://wiki.ubuntu.com/MeetingLogs/ | 19 Jun 13:00 UTC: Desktop Team | 19 Jun 20:00 UTC: Security Team | 20 Jun 16:00 UTC: How to run a Bug Jam | 21 Jun 17:00 UTC: Xubuntu Community | 21 Jun 19:00 UTC: How to run a Bug Jam === riot_l1 is now known as riot_le === thekorn_ is now known as thekorn [13:05] hi anyone can bring me in contact with a speaker from canoncial for an open source conference ? [13:06] ace_suares: speak to jono (he's on irc) [13:07] Hobbsee: Hi ! ty i'll contact. === atoponce is now known as encryptz [13:55] hey hey [13:56] hi [13:57] oh noes, a pitti and a kwwii! [13:57] * pitti throws a chocolate bar at Hobbsee [13:58] hi [13:59] yo there [13:59] pitti: thanks for all the help with the hardy packages, I owe you a drink :-) [13:59] mvo, Riddell, seb128: ping [13:59] kwwii: heh, no problem [14:00] hi [14:00] hello [14:00] was just talking to seb in -devel [14:01] pitti: \o/ [14:01] Keybuk: hey [14:01] ok, let's get started [14:01] https://wiki.ubuntu.com/DesktopTeam/Meeting/2008-06-19 [14:02] I actually put together the meeting agenda this time ;-) [14:02] hey mpt [14:02] Keybuk: let's see if you manage to write minutes too ;-) [14:02] I didn't note any actions from last week's meeting, did anyone think they took one? [14:02] Keybuk, the GtkStatusIcon/Tray-Icon stuff is solved? [14:03] Sorry, I didn't realize I was expected in the meetings until I was actually spending time on Ubuntu :-) [14:03] MacSlow: I was going to ask you ;-) [14:03] mpt: you're not expected, but welcome to attend if you wish ;P [14:03] Keybuk, I didn't remove it [14:03] MacSlow: err? missing context here [14:04] I think he's speaking about the action item for this one [14:04] ah, right [14:04] [14:19] Keybuk, I can try to ask around my contacts at Imendio to see if they have some short-term hireable man-power left over, ok? [14:05] last time I looked (earlier this day) there still was a buttlet-point regarding the tray-icon spec and GtkStatusIcon issue in regards to RGBA-theme-engines (murrine) [14:05] MacSlow: did you ask around? [14:05] Keybuk, yeah... but I didn't get any responses sofar... only from Ryan and he's only available no earlier than september [14:06] MacSlow: do you think that it's worth continuing to ask around? [14:06] can you think of any other approaches to solve the problem? [14:06] Keybuk, drop RGBA for intrepid is the only "solution" I currently see :/ [14:06] Keybuk, there should be a good bunch of free OLPC people now, probably there is someone mong them [14:06] *among [14:07] MacSlow: you don't know anybody who could do the work, including yourself? [14:07] does the murrine author not have any input? [14:07] could the panel simply be not transparent? :p [14:08] A transparent panel? Why? [14:08] until now I have not set it to be transparent anyway (and had no immediate plans to do so) [14:08] until now only a few apps can do rgba natively anyway :-( [14:08] I'm maybe missing why this is a critical blocker [14:08] Keybuk, well I probably could, but considering the time I've left to deliver the face-browser... I don't see me getting the tray-icon spec and GtkStatusIcon fixed before Feature/UI freeze for Intrepid [14:09] I thought the idea was to make panel items work against an opaque-but-not-necessarily-flat-color panel [14:09] MacSlow: if we don't get changes to gtkstatusicon, what does that mean? [14:09] Keybuk, but like I said... my lack of experience in that domain will cause me to take quite some time on it [14:10] mpt: yeah, that is part of it as well [14:10] MacSlow: it's your call ;) [14:11] Keybuk, we will not be able to have RGBA as default colormap for every created GTK+-widget... that will cause the the notification-area to go "haywire" [14:11] Keybuk, I rather stick to the face-browser and do scheduled work [14:11] ok [14:12] solved then :-) [14:12] Keybuk, if we want some RGBA in GTK+-apps still for intrepid we'll have to do it on a per-app basis... e.g. just like I did for the dialogs of libgksu, gnome-session logout [14:12] yours is the next agenda item too [14:12] * MacSlow: Clutter version [14:12] For gdm-face-browser clutter-0.7/0.8 is needed, but from debian we only get 0.6.x [14:12] update ;-) [14:12] there are a lot of nice fixes in 0.7/0.8 [14:12] nothing is using it in the archive anyway so that's not going to create issues [14:13] that's just a library, shouldn't be too hard? [14:13] seems a no-brainer [14:13] and I already started doing a PPA for clutter/clutter-cairo/clutter-gtk 0.7~svn20080619 [14:13] MacSlow: update clutter at your leisure [14:13] and for intpreid most are compiled aready... [14:13] but for the some days to come I'll stick to hardy on my desktop box for coding [14:14] MacSlow: you could upload it to your ppa against hardy [14:14] I'll have to cut the -doc stuff atm, because that would collide if installed in parallel with clutter 0.6.x & Co [14:14] MacSlow: don't worry about parallel install [14:14] mvo, I'm about to do that... but then meeting time came :) [14:14] just update the package [14:14] we don't need to install in parallel [14:15] I initially suggested to have them installable in parallel, but maybe we don't need that [14:15] nothing is using 0.6 anyway [14:15] seb128, Keybuk: well but I want to do it right :) [14:15] MacSlow: doing it right is updating the package ;) [14:15] seb128, indeed [14:15] doing it right is not keeping old non maintainer code in the archive [14:15] so just update [14:15] Keybuk, what's nearly done already :) [14:15] s/maintainer/maintained [14:15] Keybuk, first time package-training really paid off for me :) [14:16] ok, action for you: [14:16] * MacSlow to update clutter to appropriate version, not worrying about parallel install [14:16] if anybody is interested -> https://edge.launchpad.net/~macslow/+archive [14:16] outch clutter-gtk quirked [14:17] MacSlow: feel free to ask questions on #ubuntu-desktop if you have issues during the update [14:17] ok [14:17] seb128, sure... thanks! [14:17] nothing I can see in the sponsoring queue that requires attention [14:17] and no desktop bug list for intrepid yet [14:18] Merges. [14:18] "clean your items before than Daniel jump from a roof because there is too many things to sponsor"? ;-) [14:18] "scott (41)" ... tsk :) [14:18] * MacSlow rushes to the loo [14:18] * kwwii hopes he makes it [14:18] but we really don't want to keep readahead-list, do we? [14:18] pitti: I keep unsubscribing the team, and he keeps putting it back [14:18] Keybuk: right, what I figure; we want prefetch in intrepid for real? [14:19] (pleeease...) [14:19] maybe [14:19] prefetch is ... [14:19] well, let's talk about that outside of the meeting if you're interested ;) [14:19] anywa [14:19] right [14:19] MERGES [14:19] 200+ to go [14:19] kwwii, Du Tuppes! :) [14:19] and not long left to do them [14:20] 203! [14:20] all hands on deck for them please, including MacSlow ;) [14:20] * pitti is happy that he grinded through all of his now [14:20] but I can help out with some others if required [14:20] * mvo is attacking them since this morning [14:20] Keybuk, what does that mean? [14:20] MacSlow: http://merges.ubuntu.com/main.html [14:20] speaking about those there is quite some done by contributors waiting for sponsoring ;-) [14:20] (well since a couple of days of course, but with more force since this morning) [14:21] * ogra wonders if tedg is on vacation, there is a xscreensaver merge sitting on MOM [14:21] I think seb128 has a point, we should go over our sponsoring tiem again [14:21] ogra: there is a sponsor request open for this one [14:21] i was perpared to upload that for him ... [14:21] ogra: he's moving house [14:21] seb128, well, i didnt see any yay or nay from ted on it [14:21] * mvo is guilty of letting those slip too [14:21] ogra: bug #229618 has your name on the sponsoring list [14:22] seb128: Colin already covered those last night ;) [14:22] unless there's new ones that I missed [14:22] seb128, yes, i asked dholbach million times to not put me on it but ted, i dont do xss gss since 3 releases now [14:22] ogra: ted doesn't have upload rights to sponsor it though [14:22] seb128, right, but he should review it [14:23] alright [14:23] so I volunteer for going over the list and pick a few from non-canonical folks, but I don't want to do too many any more; I spent plenty of time on merges already [14:24] How is it decided who does what? [14:24] ogra: subscribed Ted - excusez-moi [14:24] MacSlow: do any that you can [14:24] and don't feel limited by packages you've touched before [14:24] ogra: and "million times" is a bit much [14:24] merges are a great way to learn packaging [14:25] Keybuk, I expected a comment like this :) [14:25] dholbach, well, three i think, sorry if i wouldnt be that busy i would have pinged him already, not really your fault :) [14:26] do people want to go down the merge list and assign them out? [14:26] what's with the color-coding there? [14:26] or are you happy to grab them as you can? [14:27] MacSlow: mostly meaningless [14:27] * mvo is happy with just grabbing them [14:27] * MacSlow has no idea what to address... [14:27] MacSlow: if you have questions about whether a patch is still necessary, procedure, or sponsoring, feel free to ask me; if you merge, you'll eventually learn more about packaging, indeed [14:27] but I feel I don't want to tackle huge stuff like gcc or gimp [14:27] * MacSlow is scared like hell [14:27] MacSlow: that's the package's Priority: field, but it's not very interesting [14:27] MacSlow: gtk+! [14:27] MacSlow: gimp should be easy for you, it's just a GTK+ app with a couple of small patches [14:27] MacSlow: nah, start with easy stuff [14:27] and it looks like there's a bug in the sponsor queue for it already ;) [14:28] MacSlow: planner (another small GTK+ app) [14:28] oh... I'll do gtkglext! [14:28] gnome-pilot-conduits [14:29] gimp is in the sponsoring queue already - who wants it? [14:29] and I'll take on gimp then [14:29] dholbach: macslow [14:29] gnumeric? that's only a small patch [14:29] * MacSlow grows bold [14:29] gnome-netstatus also [14:29] gimp is in the SPONSORING QUEUE already :-) [14:29] dholbach, which means? [14:30] MacSlow: http://people.ubuntu.com/~dholbach/sponsoring/ [14:30] MacSlow: the merge is done, waits for a review and upload [14:30] MacSlow: someone's already done the work, it just needs a review and an upload [14:30] * dholbach hugs Keybuk [14:30] ah ok [14:30] dholbach i've filled that a minutes ago [14:31] MacSlow: that's a handful that should be easily doable by you :p [14:32] ok [14:32] any other business for today? [14:32] yes [14:32] packagekit [14:32] seele: what's your agenda item? [14:32] dholbach, I tell you which merges I want to tackle? [14:32] pitti: explain? [14:32] MacSlow: no, just go ahead and do them [14:32] Keybuk: jono pinged me back to you about usability testing swag for participants [14:32] Keybuk: not sure if he talked ot you or not [14:32] MacSlow: no, not necessary - I'll take care once it's in the sponsoring queue [14:32] I wanted to ask around who else is insterested in getting PK working in intrepid soon [14:32] seele: he asked me if I thought it was a good idea, I said yes [14:33] personally I'd really like to get it for jockey, and I need it for getting rid of more gksu desktop files [14:33] ATM it's in pretty non-working shape, so if we want it, we need to allocate some resources to it [14:33] I'm interested in doing it, but I wanted to know who else needs it, and maybe help out [14:34] pitti: I've got it vaguely working on a machine here. [14:34] james_w: 0.2.2? on intrepid then? [14:34] * pitti currently installs intrepid to try it out [14:34] pitti: i.e. pkcon install whatever works. [14:34] james_w: wow, didn't work for me; let's talk aobut it in #u-devel after the meeting, if you like? [14:34] pitti: there is a bzr report/git repo for that with the 0.2.x branch [14:34] pitti: intrepid, and something around 0.2.2, with a couple of patches to the apt backend. [14:34] pitti: sure. [14:34] Keybuk: ok.. we were hoping to do this mid-July. is it possible to get something by then or is it too soon? [14:34] ah, ok [14:35] Keybuk: shoudl i go back to jono about this now that you've blessed it? [14:35] seele: I'm not going to have any capacity to help with it, so Jono is your best bet [14:35] Keybuk: ok thanks [14:35] seele: my blessing isn't required ;) I don't have budget approval [14:37] james_w: is your branch based on the git branch of glatzor? [14:37] pitti: sounds like it needs more testing to determine what work is required? [14:38] Keybuk: yeah; I'll talk with James and try to get it working for me first, then I'll talk to glatzor about updating the package to 0.2.2 [14:38] pitti: ok, great [14:38] mvo: no, on trunk [14:38] it was mainly an "oh, I need that too" straw poll [14:38] * mvo nods [14:39] ok [14:39] any other any other business? :-) [14:39] pitti: gnome-control-center 2.23 upstream code can use it to install themes, that would be nice to have too [14:39] seb128, mvo: it would be useful for upstreamizing easy-codec-installation, too, I figure? [14:39] yes [14:40] though we have a working solution there so that's not high priority [14:40] pitti: yes, we just need to solve the problem to figure out how the packages are called on different plattforms [14:40] distros I mean [14:40] but that is a general pk problem [14:40] right, at least the UI part, I mean [14:40] yes [14:41] mvo: maybe with particular provides? "Provides: video-codec-mpeg-4" or whatever [14:41] mvo: that's similar how OpenSuSE and RedHat encode driver vendor/product IDs to pacakges [14:41] pitti, i think plokit should be fixed before we rely on it wth more apps ... the missing password caching is *massively* nnoying [14:41] *polkit [14:41] password caching? [14:42] first time I hear about such a problem? what is the problem? [14:42] pitti: yeah, I think there are some plans for this from debian already, so that fits nicely [14:42] you have to give your password for *every* action ... unlike gksu which caches it for 10 min [14:42] ogra: no, that's not true [14:42] ogra: that's configurable in the policy [14:42] well, then we should fix the policy [14:42] you can say that you keep a privilege for the session, or forever [14:42] ogra: which policy requires you to prompt each time? [14:42] it's a checkbox, and mostly enabled by default [14:42] david told me in prague it wouldnt be possible at al since he thinks its a sceurity breach [14:43] ogra: I think you possibly confused him by referring to it as password caching [14:43] but if thats possible now, i'm fine, lets just enable it [14:43] when what you really meant was that PK authorizations shouldn't expire immediately [14:43] it's already there [14:43] for me it asks every time here on a clean hardy [14:43] ogra: for which authorization? === foobottu changed the topic of #ubuntu-meeting to: Current meeting: Desktop Team | Calendar: http://fridge.ubuntu.com/event | Logs: https://wiki.ubuntu.com/MeetingLogs/ | 19 Jun 20:00 UTC: Security Team | 20 Jun 16:00 UTC: How to run a Bug Jam | 21 Jun 17:00 UTC: Xubuntu Community | 21 Jun 19:00 UTC: How to run a Bug Jam [14:43] Keybuk, any that polkit is involved with [14:43] ogra: not true [14:43] g-s-t uses auth_admin, not auth_admin_keep_*, so they will show it [14:43] yes, for g-s-t [14:43] each authorization is configured differently [14:44] open time-admin ... click on unlock ... close time-admin [14:44] g-s-t does happen to just use "Admin Authentication" [14:44] but that's just g-s-t's very weird usage of PK [14:44] you will need to unlock again if you open it again now [14:44] ogra: check it with mounting an internal disk [14:44] if you do system -> admin -> authorizations -> manage system config -> Implicit Auth -> Edit -> Admin Auth (keep session) [14:44] then you'll only be asked once [14:44] i dont want to be asked once ... i want consitent behavior [14:45] so that should indeed be fixed in g-s-t [14:45] ogra: the bug here is that g-s-t doesn't use PK properly [14:45] gksu times ut after ten mins [14:45] pk will alllow it al the time or not [14:45] g-s-t needs to split the privileges, and have more sensible defaults for how long ot keep them [14:45] there is no timeout mechanism [14:45] a timeout would not be hard or invalid to add [14:45] right [14:46] though gksu doesn't have a timeout ;) [14:46] thats what i was after :) [14:46] well, inherited from sudo [14:46] (at least, I don't think it does -- I thought it was based on tty tickets :p) [14:46] oh, no, sudo does have that 15 minute thing doesn't it [14:46] yeah [14:46] right [14:47] pitti: do you see any reason why a (keep for 15 minutes) couldn't be added along with session and indefinitely ? [14:47] Keybuk: no, for corner cases like g-s-t that should be fine; however, it should be per-privilege, not global [14:47] pitti: agree [14:47] Keybuk: davidz was against it [14:48] james_w: any particular reason? [14:48] though perhaps only globally [14:48] it doesn't seem much different than "keep session" [14:48] I didn't ask for more details as we were in the middle of a session [14:48] Keybuk, he considered it a security issue, as i said above [14:48] ogra: as I said, I think you explained what you wanted wrong [14:48] * ogra dscussed it over a beer, no session involved ... but the outcome was the same [14:49] if you talked about caching passwords, then I can definitely see why he thought that was a security issue [14:49] the whole point of PK is that you _don't_ need a keyring for the passwords [14:49] yeah, might be since i referred to gksu which likely behaves different in fedora :) [14:49] what you actually wanted was for PK authorizations to timeout [14:49] ogra: they don't have gksu [14:49] or sudo [14:49] they do, but dont use it :) [14:49] F9 GUI is pure PK [14:49] right now, a PK authorization can be one shot (do action, and forget authorization) [14:49] well, not by default in the deskop, I mean [14:50] Keybuk, very scary [14:50] per-session (do action, and be able to repeat the action until you log out without being prompted) [14:50] and indefinite (do action, and never be prompted again) [14:50] right, like a graphical rootshell :) [14:50] what you should have asked for was another state between one shot and per-session [14:50] yeah, i see that now [14:50] which is an authorization granted for a short amount of time, or the end of the session, whichever is sooner [14:51] I think David didn't implement this so far because he thinks it's wrong design-wise [14:51] (I had a quick talk about PK with him) [14:51] that what he said as well [14:51] *thats [14:51] oh [14:51] I could definitely see that David doesn't like timeout authorizations :p [14:51] the idea of PK is that you auth for something once, and shoudlnt' be bothered about doing the same action henceforth [14:52] instead of gksu, which will ask you over and over again === Tweenaks is now known as Treenaks [14:52] since the fewer password request you get, the more attention you actually put to them [14:52] s/put/pay/ (I think) === bureflux is now known as afflux [14:53] we're almost out of time now :) [14:53] any other any other any other business? :-) [14:53] yeah, got sidetracked, sorry [14:53] KitKit! [14:53] pitti, well, its like the difference between su and sudo :) [14:53] ogra: yeah, su is worse [14:54] have a rootshell or use sudo [14:54] ok, adjourned [14:54] thanks everyone [14:54] thanks all [14:54] yipee.. food-time [14:54] * mvo waves [14:54] thanks === skateonmars is now known as skateinmars [15:16] @schedule Paris [15:16] Zic: Schedule for Europe/Paris: Current meeting: Desktop Team | 19 Jun 22:00: Security Team | 20 Jun 18:00: How to run a Bug Jam | 21 Jun 19:00: Xubuntu Community | 21 Jun 21:00: How to run a Bug Jam [15:19] Zic: Schedule for Europe/Paris: Current meeting: Desktop Team | 19 Jun 22:00: Security Team | 20 Jun 18:00: How to run a Bug Jam | 21 Jun 19:00: Xubuntu Community | 21 Jun 21:00: How to run a Bug Jam [15:19] hu :] [15:20] @now [15:20] stgraber: Current time in Etc/UTC: June 19 2008, 14:20:03 - Current meeting: Bugs for Hugs Day === ubottu changed the topic of #ubuntu-meeting to: Current meeting: Bugs for Hugs Day | Calendar: http://fridge.ubuntu.com/event | Logs: https://wiki.ubuntu.com/MeetingLogs/ | 19 Jun 20:00 UTC: Security Team | 20 Jun 16:00 UTC: How to run a Bug Jam | 21 Jun 17:00 UTC: Xubuntu Community | 21 Jun 19:00 UTC: How to run a Bug Jam | 22 Jun 18:00 UTC: Ubuntu Mozilla Team === leonel_ is now known as leonel === rraphink is now known as raphink === effie is now known as effie_jayx === smarter_ is now known as smarter === dudus_ is now known as dudus === evand_ is now known as evand === ubottu changed the topic of #ubuntu-meeting to: Current meeting: Security Team | Calendar: http://fridge.ubuntu.com/event | Logs: https://wiki.ubuntu.com/MeetingLogs/ | 20 Jun 16:00 UTC: How to run a Bug Jam | 21 Jun 17:00 UTC: Xubuntu Community | 21 Jun 19:00 UTC: How to run a Bug Jam | 22 Jun 18:00 UTC: Ubuntu Mozilla Team [21:07] i'm late, apologies [21:08] Me too. [21:08] hiya Casey_ [21:08] propagandist: around? [21:08] heyya [21:08] hi! [21:09] kees: yup [21:10] #startmeeting [21:10] Meeting started at 15:12. The chair is kees. [21:10] Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE] [21:10] [topic] CVE review [21:10] New Topic: CVE review [21:10] just a quick overview on CVEs... anything anyone wants to bring up here? [21:11] I don't have anything [21:12] [topic] SELinux update [21:12] New Topic: SELinux update [21:12] propagandist: how're things in the Great Merge with Debian? :) [21:12] kees: heh, i think that i've narrowed down the changes to just a few minor ones in the main packages [21:13] the one that needs to most changes will be refpolicy [21:13] propagandist: cool. I assume it makes sense to have a fork of refpolicy due to the differences between the OSs [21:13] the last i talked with manoj though it sounded like we could get that squared away sooner or later [21:13] ah, okay [21:14] propagandist: anything you need from me or other ubuntu devs? [21:14] mm true, there will probably be some forking [21:14] kees: not at the moment, but i'll be sure to let you know if i do ;o] [21:15] propagandist: heh, okay. the auto-import-from-debian ends on the 26th, so after that (and before feature freeze) we just need to make sync requests (no justifications needed) [21:16] ah, kk, i'll try to get as much done before that as i can [21:16] [topic] Smack [21:16] New Topic: Smack [21:16] Casey_: I read through the whitepaper you sent -- sounds like services need to be patched to use smack? [21:16] Well ... [21:16] No. [21:17] heh, okay. [21:17] That is, they don;t all need to. [21:17] And it depends on the use you're putting them to. [21:17] sure, understandable. [21:17] The three uses (single, multiplexed, cognizant) [21:17] fundamentally, we want to isolate the cups daemon from anything it doesn't need access to [21:18] Is there any way to get the clients and an unmodified server running in different contexts without using the poly server? [21:18] If you run system processess at "_" [21:18] and users at "Blah" [21:19] You can set up CUPS as either single level Blah or "mastered" at floor [21:19] win 26 [21:19] There are cases for each [21:19] eek [21:20] Casey_: I read the paper and the LWN stuff, but I haven't seen what an example access rules would be that you would load into /smack/load (or wherever) [21:20] Casey_: so I feel a bit of a disconnect [21:20] I'm thinking of the case where we want CUPS at one level 'cups_blah' and the clients at another 'cups_c' [21:20] Ok [21:20] Here goes .... [21:22] smackpolyport -c -m :cups_blah ; cups --port ,,,, [21:23] Everyone will be able to talk to CUPS even though it's running at cups_blah [21:23] smackpolyport does all the provileged stuff. [21:23] (this is multiplexed) [21:24] Right. In particular, you're using a "safe" master for all client labels. [21:24] Casey_: can you give an example rule that tells what the safe master can do? [21:24] excuse me if my terminology is wrong [21:25] Casey_: ah, kk, so the only way to do that is through the polyport yes? [21:25] The cups process (not the cups program) is constrained to its label. [21:25] * jdstrand nods [21:26] You could also do it using rules thus .... [21:26] so all the files that it can touch need to be labelled with "cups_blah" ? [21:26] Right [21:26] ah [21:26] lightbulb [21:26] yeah, that was the leap I hadn't made yet [21:26] cups_blah cups_c w [21:27] Casey_: so then there is Netlabel for the networking parts? or is that something different [21:27] cups_c cups_blah w [21:27] Those two rules in /etc/smack/accesses (writen to /smack/load) [21:28] whould allow the processes to talk to each other [21:28] without using a multiplexer [21:28] Smack uses netlabel. [21:29] Casey_: what do you see as "next steps" for Smack in Ubuntu? The 2.6.26 kernel is in intrepid now, so people could boot with smack enabled now. [21:29] With those two rules the processes can't access each others files, that needs read access. [21:29] Casey_: so your smackpolyport command is really for connecting processes for communication. you'd still need to define all the labels for the diferent files touched-- correct? [21:30] Casey_: wouldn't that also allow the clients to write to the servers conf files? [21:30] (and therefore smackpolyport is optional) [21:30] Write access to files requires read access as well [21:30] ah [21:31] This is a sneekly artifact that makes servers easier [21:31] because you don't need read access for packets [21:31] I'd still like to see a Wiki document (e.g. https://wiki.ubuntu.com/UsingSmack) that is similar to the docs for AppArmor: https://help.ubuntu.com/community/AppArmor [21:31] interesting... [21:31] re wiki> me too [21:31] especially for helping people enable it, tweak things in the right places, etc. [21:32] helping people with how to label files is, I think, the critical bit [21:32] and for methods of contraining labels [21:32] If y'all are willing to host it, I'm happy to populate a wiki [21:32] AppArmor consolidates that into profiles, and SELinux (iiuc) has utilities to convert policies into labels [21:32] Right. [21:33] With Smack you don't define labels [21:33] You use them [21:33] Casey_: yeah, start at https://wiki.ubuntu.com/UsingSmack and explain it like https://help.ubuntu.com/community/AppArmor [21:33] Ok on the wiki then. [21:33] Casey_: without labels written to disk, processes aren't very useful, IIUC [21:34] attr -S -s SMACK64 -V 'MyDogHasNoNose' foo [21:34] propagandist: is that accurate, btw: "SELinux has utilities that convert a policy into on-disk labels"? [21:34] Casey_: while that might be second-nature to you, that's exactly the information I need. :) [21:35] and where does the r/w access mark go? [21:35] kees: mostly ;o] [21:35] Smack does FS defaulting (usually to '_') [21:35] The r/w is in the rule. [21:35] The basic rule is that if labels don't match there's no access [21:36] an explicit rule (/etc/smack/accesses) "foo bar rw" [21:36] says any process at foo can read or write an object at bat [21:36] s/bat/bar/ [21:37] There is no access spec attached to the file [21:37] Casey_: so I could organize labels like cupsd_rw for all the files cups needs r/w access to [21:37] Casey_: and all labels/constrainsts need to be written in one monolithic file, /etc/smack/accesses, or no? [21:37] and cupsd_r for files cups only needs to read. [21:37] and then cups cupsd_rw rw cups cupsd_r r [21:38] in the accesses file? [21:38] and then label all the files with cupsd_rw and cupsd_r [21:38] (or have generalized labels like nameservice_r and define cups nameserver_r r [21:38] ? [21:39] kees: I think we'd need to do the later for quite a bit [21:39] jdstrand: yeah, all "abstractions". [21:39] kees: so other processes could get at them [21:39] Casey_: it sounds like people (well, me) need a "recommended best practices" for how to go about choosing labels for on-disk files, and examples for shared files, etc [21:39] In general, you can run all your system services at '_' and that will protect them from users, who may run at 'User' [21:40] Yes, [21:40] I was thinking about the interaction between cups and cups-pdf, and this 'abstraction' idea might be the way to do it [21:40] I want to protect my users from services. ;) [21:40] Ah [21:40] but, yeah, [21:40] same all around. [21:40] Well, again, services at _ can't write users at User [21:40] okay, I feel like I have a better understanding here. [21:40] well, I think protecting services is one thing, and users is another-- both are useful and desirable :) [21:41] There are folks who think each way [21:41] Both can be right [21:41] If you think "different implies no implicit access" you're good [21:41] Mostly [21:42] okay, so docs with examples and maybe a "best practices" for people to follow is "next steps", how does that sound? [21:42] No rest for the wicked. [21:42] [action] Casey_ to build up https://wiki.ubuntu.com/UsingSmack into something resembling https://help.ubuntu.com/community/AppArmor, along with possible "best practices" and examples. [21:42] ACTION received: Casey_ to build up https://wiki.ubuntu.com/UsingSmack into something resembling https://help.ubuntu.com/community/AppArmor, along with possible "best practices" and examples. [21:42] :) [21:42] Casey_: is /etc/smack/accesses is single monolithic file, or can it be broken out into smaller bits? [21:43] Casey_: this could be important for packaging [21:43] smackaccesses should remain small. [21:43] Do you really need to protect CUPS from SSH? [21:43] why wouldn't we? [21:44] or rather, in a perfect world, yeah. [21:44] they deal with different protocols, software, users [21:44] maybe this is conceptually 'default deny' vs 'default allow' [21:44] Ah, why should you? [21:44] Really, what value do you obtain> [21:44] Casey_: paranoia? :) [21:45] I've seen some admins really want very strict separations [21:45] but I understand that Smack is supposed to fill the middle ground [21:45] They have SELinux if they're Granularity Gremlins [21:45] hehe [21:46] 800,000 lines of policy [21:46] Does that make you feel secure? [21:46] Casey_: is it safe to say that configuring cups for smack protects cups from others, rather than prtecting others from cups? [21:46] It works both ways. [21:47] DIfferent labels with controlled access between them (default == none) [21:47] yes, it *can*, but it sounds like the general practice is the former. perhaps I am missing something [21:48] Well, services are an interesting problem .... [21:48] perhaps I should wait and read your wiki, and things will be more clear [21:48] each seems to have it's own issues/ [21:48] I feel I have a better understanding as is, but the practical application/best practices are what I'd like to see [21:48] CUPS needs to to top&bottom labeling for LSPP [21:49] It will need to be cognizant, eventually. [21:49] sorry to possibly cut discussion short -- I've got to head off to other things. Is meeting again in 2 weeks good? that'd be the 3rd of July, same time. [21:49] Casey_: speaking of that, is this something you hope to get upstream, and if so, how are upstreams reacting to smack? [21:50] Slowly. I have lots more work to do .... [21:50] kees: the 3rd is good [21:50] selling the value, they all would like to see a disto take the lead, [21:51] so they don;t end up with dead code in a year [21:51] The 3rd is ok by me, too. [21:51] #endmeeting [21:51] Meeting finished at 15:54. [21:52] feel free to keep discussing -- I just have to split :) [21:52] Ok, thanks. Anyone what to hear more? [21:52] kees: good meeting, thanks kees [21:52] thanks kees! [21:53] Casey_: ;o] of course [21:53] thanks everyone for coming. :) [21:53] Thank you [21:53] Casey_: I'm quite interested in smack, but would like to read your wiki. then I'm sure to have a bunch of questions :) [21:53] No doubt [21:53] Casey_: Will all services need be smack aware under LSPP? [21:53] Nope. [21:53] Many will [21:54] i think the correct question is "will smack ever be certifiable under LSPP" [21:54] Some are just uninteresting, serving up "public" information [21:54] Method: yes [21:54] wrong answer [21:54] :) [21:54] DO tell [21:55] Casey_: thanks, i'm looking forward to your wiki [21:55] you can't implement both a lattice and category sets at the same time [21:55] at least not easily [21:56] selinux wouldn't have needed explicit mls support if TE alone was sufficient [21:56] Method: I can describe how it's done, but it's more than one line. [21:57] i'm aware, we've had this converstation before :) [21:57] Well then. [21:58] The issue is a complete set of labels implied by the lattice, which is large, verses the actual used set, which in practice is small. [21:59] Real MLS installations use 3 site defined labels. [21:59] Either 3 levels or 3 categories [22:00] Since the late 1980's I have never sween them mixed. [22:00] well, i'm working with someone now that uses several levels and hundreds of categories [22:00] All at once? [22:01] yep, on tsol currently [22:01] Is anyone ever in more than one category at a time? [22:01] most users are in most categories [22:01] plus they are using some categories for releasibility [22:01] their label_encodings file is scary :\ [22:02] I bet. In the end they just use the aliases I suspect [22:03] For the accesses they really want, I have a beer says the smack rules would be simpler [22:03] they use prefixes for releasibility [22:04] which may be true, but that doesn't mean anyone will consider that sufficient for lspp ;) [22:06] I've been through the LSPP (and B1) mill and had to do some serious education, and I think that this is simple enough to get the point through. [22:06] Maybe a tool to generate rules based on B&L, or to check that a rule set doesn't violate B&L [22:07] I've done sillier things [22:07] Looks as if the next meeting here is ramping up. [22:08] Thank you. Ta. [22:09] (feel free to move to #ubuntu-hardened) [22:09] oop === ubottu changed the topic of #ubuntu-meeting to: Current meeting: Bugs for Hugs Day | Calendar: http://fridge.ubuntu.com/event | Logs: https://wiki.ubuntu.com/MeetingLogs/ | 20 Jun 16:00 UTC: How to run a Bug Jam | 21 Jun 17:00 UTC: Xubuntu Community | 21 Jun 19:00 UTC: How to run a Bug Jam | 22 Jun 18:00 UTC: Ubuntu Mozilla Team | 24 Jun 15:00 UTC: Server Team