== Meeting information == * #ubuntu-touch-meeting Meeting, 12 Aug at 20:03 — 21:19 UTC * Full logs at [[http://ubottu.com/meetingology/logs/ubuntu-touch-meeting/2014/ubuntu-touch-meeting.2014-08-12-20.03.log.html]] == Meeting summary == ''LINK:'' https://code.launchpad.net/~ubuntu-filemanager-dev/ubuntu-filemanager-app/require-screenlock-password/+merge/230058 == Vote results == == Done items == * (none) == People present (lines said) == * dpm (49) * sarnold (48) * ajalkane (43) * meetingology (3) * popey (1) == Full Log == 20:03 #startmeeting 20:03 Meeting started Tue Aug 12 20:03:03 2014 UTC. The chair is dpm. Information about MeetBot at http://wiki.ubuntu.com/meetingology. 20:03 20:03 Available commands: action commands idea info link nick 20:03 so essentially, the main topic today is the security checks branch: 20:03 https://code.launchpad.net/~ubuntu-filemanager-dev/ubuntu-filemanager-app/require-screenlock-password/+merge/230058 20:04 I'd like to see if we can come up with a solution for RTM that is doable and still secure 20:04 What's RTM dead-line? 20:05 end of August, although we'd like this to land as soon as possible 20:05 we originally targeted the 7th August 20:05 and thanks ajalkane for getting your branch submitted before that 20:06 so ajalkane has assessed the options from his POV at https://code.launchpad.net/~ubuntu-filemanager-dev/ubuntu-filemanager-app/require-screenlock-password/+merge/230058/comments/559751 20:06 and sarnold has already looked at this from the security POV 20:07 sarnold, what do you think of those options? As said before, my concern is that I don't think we might be able to deliver a full-blown PAM plugin by RTM 20:07 or do you have other suggestions? 20:08 dpm: unfortunately, I'm very new to qml, and I don't know what's possible or clean in it 20:08 dpm: I agree with ajalkane that multithreading the interactions is probably going to be more complication 20:09 dpm: .. and doing our own qt event loop in another thread is way beyond my experience, but that also feels like it's going to be fraught with complications 20:09 One clarification to my post is, that the 1) option in my first post is something that probably could be done in number of days instead of weeks. The other ones are more problematic. 20:10 so, even though there is a risk of the PAM module blocking execution of the UI thread, I think that's the option that makes most sense 20:11 Ah I forgot that blocking of UI thread. The problem is that if Pam module wants to display UI it can't block the UI thread. It'd just hang 20:11 hm, bummer 20:11 I don't think the PAM module should be calling into Qml, that also sounds like trouble; but the existing conversation function feels like it is 90% of the way there -- as I see it, it probably just needs to make visible the right dialog boxes at the righ time 20:11 Pam library is a little troublesome in that way, that it's not asynchronous conversation. It's synchronous. 20:12 So it practically needs to have a separate thread for back and forth passing of data 20:12 ajalkane, you had a look at how the ubuntu settings app does authentication - is this something we could learn or reuse from that? 20:12 I think it was calling unix binaries, though, IIRC 20:13 ajalkane: but is it really a trouble? it'll be blocked on the user to type in e.g. a password, and then turn around to authenticate the password 20:13 I had a little look at various pieces of code, some of them used Gnome code which I have no good understanding, some of them called directly unix commands 20:13 ajalkane: granted, if it goes away to call an LDAP server or RADIUS server it could be gone for a while -- and even average case might be a second or two -- but until authentication succeeds or fails, it's not really safe to continue, is it? 20:14 sarnold: it's a problem if we use Qt to display the asking of password. If Qt's UI thread is blocking asking for pam module to authenticate, and the pam module in turn asks Qt's UI thread to display a dialog, it probably don't work - but I'm not totally sure 20:15 * popey returns 20:15 ajalkane: I don't think the second half of that would happen -- all the interactivity happens in your conversation function, which you control, right? 20:16 sarnold: depends how this is setup. Is the conversation function ran in another thread, or in Qt's UI thread? 20:16 ajalkane: I'm thinking in the Qt UI thread 20:17 I'm sorry I'm not more experienced with Qml and Qt; it's been on the tail end of my todo list for far too long 20:17 If it's ran in Qt's UI thread then Qt's UI thread has to have made a blocking call to the pam library. Pam library making a blocking call to the Qt's UI probably will make the whole thing stuck. 20:18 I'm thinking the processing of events is stuck when making the call to pam library. Pam library trying to pass events to Qt at that point won't work. But this is also just best-guess from me. 20:19 ajalkane: when would Pam make a call into Qt's UI? would that be for more complicated modules that require something beyond just text-based interaction? 20:19 sarnold: Even text-based interaction would require calling Qt's UI, just to let user enter the password. 20:20 That's why the current implementation asks for the password before doing the pam authentication - so that we have the password to answer with when pam conversation callback needs it. 20:23 yeah, once I figured out why you were asking for the password first, it all made more sense :) 20:24 it sure feels like you ought to be able to define a few more dialogs similar to the one hidden by the Button "Unlock full access"'s onclicked: piece... 20:24 have their visible: components be set or unset by the conversation callback 20:25 and have the dialogs kick off the next back-and-forth with the conversation callback 20:26 That'd need launching a separate thread for PAM authentication and all the nasty signalling between threads with that 20:26 because if we're running in single thread, the passing of information can go only one way. From QML to PAM library. 20:27 Because the pam conversation function is a blocking synchronous call, not asynchronous 20:28 Not sure if that makes any sense, but ask away and I'll try to elaborate what I see as the problem 20:29 ajalkane: your conversation function currently builds the response right then.. 20:29 ajalkane: I don't think that is necessary 20:30 But if we only need to support PAM's "show some information" and not get any information (apart from password) back to QML, then that'd work with single thread 20:30 We just can't get any back-and-forth conversation between PAM library and the QML part except for pre-entered information, without using separate threads 20:31 * back to PAM library 20:31 ajalkane: as I'm imagining this working, the conversation callback would perform the same switch statement, set one of four visible: flags, and then return PAM_SUCCESS immediately.. 20:31 ajalkane: one of those four dialog boxes would then pop up, show the text from the pam_response structs, construct echoing fields or non-echoing fields.. 20:32 sarnold: that can be done. So enter password before calling pam, store PAM_TEXT_INFO and PAM_ERROR_MSG notifications and show them? 20:32 ajalkane: .. and then when the 'submit' button is hit, they'd then .... oh that's where I lose track of things.. 20:33 ajalkane: but what if the PAM module asks for the HOTP input from a google authenticator or yubikey or rsa secid? 20:33 let me go re-read the pam conversation docs :) 20:34 sarnold, do we really need to care for non-text-based authentication for RTM? 20:35 For all these options I think a separate OS provided conversation function would be the best choice - it'd be available to all applications, and only OS vendor can support all options. 20:35 I'm sure we can add them afterwards, but I think we should limit the scope to what's reasonable and still secure 20:35 dpm: I'm fine handling only text-based stuff for RTM indeed :) 20:36 ok, cool 20:36 when someone comes along with something compelling that requires something more than the usual text-based dialogs, we can handle it then :) 20:36 * dpm nods 20:36 But even in that case making it work with QML would (IMO) require a separate thread and probably own Qt Event loop or some other mechanism for handling it 20:36 ajalkane: okay, I think where I ran off the rails was in the assumption that the application could respond to the conversation callback "eventually" 20:37 dpm: I definitely agree with ajalkane here, it'd be wonderful to have the sdk provide this mechanism from the start 20:38 dpm: not every application can (or should) do PAM-based authentication, but we've got at least two right now that do (fileman and terminal), and having a unified mechanism for them to use would make most sense 20:39 sarnold, indeed, but I'm not sure if we should foresee any other applications that need authentication. We're building this mechanism simply to ensure these 2 unconfined apps are more secure 20:40 the only other one I could think of is ubuntu-system-settings 20:41 but I'm not too sure this would be a feature that would be added to the SDK roadmap any time soon 20:41 dang. makes sense though, they've got priorities same as everyone else.. 20:41 and ideally we should try to reduce the number of unconfined apps, not adding more :) 20:42 :) 20:42 so.... what's involved in kicking off a new thread to handle the pam conversation function here? 20:43 Tinkering and testing 20:43 that also sounds expensive :) 20:44 Yeah. Regarding RTM deadline, not at all sure I can put enough hours myself to make it 20:45 makes sense. 20:45 I don't think I can learn enough qt/qml to do it myself, though I can review anything :) 20:46 sarnold, ajalkane, do you think one of you could summarize what you think we should make? Just to make sure we're all on the same page 20:47 dpm: well, I think ajalkane has talked me into understanding that it can't be fixed simply. 20:49 My last post on the branch summarized the options that I can see if current implementation must be changed. My practical recommendation if RTM is to be made for sure is the current implementation with few targetted tweaks if necessary. Otherwise it's potentially expensive with high probability of not making RTM. 20:51 dpm: the current implementation would work assuming no one fiddles with their file manager PAM configuration. It kinda defeats the purpose of having authentication be pluggable :) but given the constraints, I can see that leaving it alone has its appeal 20:51 The current implementation works with passwords - if there's upcoming devices with fingerprints and other such more involved authentications methods in pipeline, then I say scratch the whole thing and work on it 20:53 I wouldn't want to -support- the current merge proposal for very long -- to draw an analogy, I wouldn't want it in an LTS release, but in one of the shorter releases it'd be an alright stepping stone 20:53 yes, my understanding also was that this was just a stepping-stone for RTM 20:53 ajalkane, sarnold, thanks. Ok, to answer these points: sarnold, how could a user fiddle with their file manager config? ajalkane, there are no plans to support more advanced authentication devices (at least afaik). If we were to go with the current implementation, do you guys think we could agree to a list of changes required? 20:54 ajalkane, indeed, that's the plan 20:54 sarnold, also note that this is a click package, so it's not got the same level of support as packages in the archive - we can more easily update the file manager app from the store 20:55 dpm: if a user edits /etc/pam.d/filemanager and replaces pam_unix or pam_extrausers with pam_permit (to disable the password entirely), the'll still be prompted for passwords 20:55 dpm: I wholeheartedly recommend Ubuntu Touch to provide it's own PAM library callback that displays the UI for authentication. Then the PamAuthentication Plugin can just launch a thread and pass it the conversation function 20:57 sarnold, but for that they'd need to use the terminal app, which would be locked, right? (the idea is to use the same QML plugin as file manager) 20:57 sarnold: I do think a user capable of that, could just as easily modify filemanager's QML file to not ask for any password 20:57 indeed, qml files are text-based 20:58 While it's annoying that user who knows how to edit the pam files, should have to edit many different files to get what he wants, is annoying. But it's not something that leaves unassuming user at risk as such. 20:58 Which is what I guess we're trying to protect here 20:59 heh, sure, disabling the password was just one possibility :) someone else might want to add pam_duo for two-factor authentication 21:01 so perhaps the current implementation is not too bad security-wise as the first iteration? 21:01 yeah 21:02 that's nice 21:02 cool 21:03 this is going in the store, right? we can ship fixes to this more simply than the full image updates, right? 21:03 is there any consensus how it should move forward or is it something to sit on for a while? OS provided conversation function or improvements to the plugin? 21:03 sarnold, indeed, it's a click package that we update in the store 21:04 ajalkane, I'd say, if sarnold agrees, the second: improvements to the current plugin in the MP 21:04 sarnold, so do you think you could do a further review in the light of the discussion here, and perhaps list any caveats that you see should be addressed post-RTM? 21:04 ajalkane: in some sense this feels like a chef's choice -- if you want to tackle a full mechanism here, that'd be great, but I can ask the sdk team if they can put some cycles on it eventually if you'd rather just be done with it :) 21:06 sarnold: I feel like this is so close to the core OS, that it'd be better for the OS developers to iterate all possibilities and implement a unifying experience. But for sure it can be done in the plugin also, but it's kind of half-way-there solution. 21:06 ajalkane: okay, thanks 21:08 ajalkane, I've come to agree from your feedback. However, it's also a matter of priorities, and for now this is not something that any other apps than the 2 unconfined ones are going to use 21:09 so it might not be something that we see the OS providing soon 21:09 dpm: yeah, I understand. Priorities are annoying in perfect world :P 21:09 lol 21:12 so we'll after feedback from SDK devs what's the course of action after RTM? I can do a little tinkering and testing, but since I have a pretty poor understanding of the requirements and also of pam libraries I'd need quite specific specifications what's needed to do any real work. 21:12 * веэлл сее 21:12 sarnold, what do you think of the suggestion to do another review to the current MP and list caveats/points that should be addressed after RTM? Does it make sense to you? 21:13 dpm: I believe ajalkane addressed all my other complaints :) 21:13 sarnold, ok, cool, so after the discussion, do you think the branch is good to go as it is? 21:13 dpm: yes 21:14 I just noticed I forgot to add the code to not allow locked accounts, so I'll just fix that to the branch 21:14 ajalkane: sweet 21:14 ajalkane, cool, thanks. And yes, I'll kick off a discussion to agree on post-RTM requirements 21:14 I'll try and fix it during this week 21:15 (I'm having a yummy upgrade from 12.04 to 14.04.1 waiting that might delay this a bit) 21:16 oh wow, good luck (should work well, though) 21:16 oof :) 21:16 I was surprised how well the last LTS to LTS upgrade work. Previously I was always reinstalling as the upgrade fucked up. * Fingers crossed * 21:16 ok, I think we can call it a meeting. To summarize: 21:16 :-) 21:17 Good summary, thanks all! 21:17 :) 21:17 lol 21:17 thanks ajalkane, dpm :) 21:17 I was going to be a bit more verbose, but that's also a good summary :) 21:18 - ajalkane to add fix to the current branch to not allow access to locked accounts 21:18 - sarnold to review again after that fix 21:18 - dpm to kick off a discussion for post-RTM requirements 21:19 Good work everyone, and thanks! 21:19 Thanks, cya next week. And thanks sarnold for taking the time to attend and work on the issues 21:19 #endmeeting Generated by MeetBot 0.1.5 (http://wiki.ubuntu.com/meetingology)