[00:00] <mjg59> You'd want a pretty definitive case before going to court
[00:00] <BenC> makes sense
[00:00] <BenC> plus, it would ripple all over the place
[00:00] <BenC> kernel headers in glibc (LGPL) come to mind
[13:45] <Kano> hi, you did not add gspca yet
[13:45] <Kano> when will you do so for 2.6.26
[14:17] <BenC> Kano: when we get to it
[14:17] <BenC> really, asking us questions like that is like trying to predict the weather
[14:17] <Kano> well the driver works, should be really easy to add
[14:18] <BenC> Kano: It will get done, just priorities is all
[17:33] <kirkland> rtg: i see you have committed a fix for https://bugs.edge.launchpad.net/ubuntu/+source/linux/+bug/242448
[17:33] <kirkland> rtg: is there a kernel built that I can install/test this?
[17:37] <rtg> kirkland: not yet. I'll upload to my PPA and get it built today.
[17:37] <kirkland> rtg: cool, update that bug with a pointer to your PPA.  myself and hallyn are willing to verify the fix for you.
[17:37] <kirkland> rtg: we're both subscribed
[17:38] <rtg> kirkland: it'll likely take a few hours.
[17:38] <kirkland> rtg: that's fine... no rush, whenever
[17:38] <kirkland> rtg: also, you might be interested that mhalcrow is working on a pretty small, simple patch to ecryptfs that would give sort of a "root_squash" capability
[17:39] <kirkland> rtg: you'd add an option to the mount params, like ecryptfs_exclusive_access_uid=1000 or something, and the kernel would check that on all reads/writes to the mounted files
[17:39] <kirkland> rtg: i think you were asking about something like this earlier
[17:39] <rtg> kirkland: which addresses my concern about root visibility on multi-user machines?
[17:39] <kirkland> rtg: yup
[17:40] <kirkland> rtg: the 5-minute patch he threw together when I asked him about it looks like: http://halcrow.us/~mhalcrow/patches/ecryptfs-excl-access-20080623.txt
[17:41] <kirkland> rtg: i'm hoping he'll get something like this into mainline soon....
[17:41] <kirkland> rtg: are we sticking with 2.6.26 for intrepid?
[17:41] <rtg> kirkland: 2.6.26 is the target version
[17:42] <rtg> kirkland: of course, we can cherry-pick some upstream fixes like this one.
[17:42] <kirkland> rtg: that's sort of what i was asking
[17:42] <kirkland> rtg: okay, let's see it get upstream first
[17:46] <rtg> kirkland: instead of "root_squash" capability, it looks more like "exclude foreign euid" capability. Can't root get around the UID issue by running a script in the context of the UID?
[17:46] <kirkland> rtg: yeah, this idea spun off the "root_squash" idea, and is intended to be even more specific
[17:48] <kirkland> rtg: but as you say, root can change his uid.....
[17:48] <rtg> kirkland: while this mount option would keep other users out, it only makes it slightly more difficult for root to go snooping.
[17:48] <kirkland> rtg: true...  hmm, ultimately, this should be key-based
[17:50] <rtg> kirkland: kees might be a good guy to ask about this. perhaps there is an AppArmor or SMACK approach the is not vulnerable to root snooping.
[17:51] <kirkland> rtg: well, there's certainly an SELinux approach
[17:51] <kirkland> rtg: add some SELinux hooks to ecryptfs is a long term goal of the ecryptfs developers
[17:51] <kirkland> rtg: but that's non-trivial, IIUC
[17:52] <kirkland> rtg: i'm not sure about AppArmor or SMACK
[18:22] <kirkland> rtg: you'll get a kick out of this....
[18:22] <kirkland> rtg: ->  mhalcrow: could we prevent root from running a script as that user and accessing the data?
 Yes. It's called SE Linux
[18:23] <rtg> kirkland: well, I guess that makes sense :)
[18:23] <kirkland> rtg: <mhalcrow> If you don't want root to be root, that's what you really need.
[18:25] <SEJeff> label based security does things path based security can't
[18:45] <kirkland> rtg: if you have a minute, i'd like to invite mhalcrow here.  i'd like to decide whether or not it's of value to do the exclusive_uid thing, or not, and i'd like your opinion on the kernel matter at hand
[18:46] <rtg> kirkland: the patch doesn't look so bad, but it doesn't really solve the root snooping issue, so is it worth it? It does keep unprivileged users from looking around.
[18:47] <kirkland> rtg: true for unprivileged users, but that can be handled just by normal DAC, chmod +700
[18:48] <rtg> kirkland: is that the default mount permissions?
[18:48] <kirkland> rtg: not a mount issue; ownership on the mountpoint/device itself
[18:48] <rtg> kirkland: right, thats what I meant
[18:49] <rtg> kirkland: so, unless there is a good use case, it doesn't seem that worthwhile.
[18:50] <kirkland> rtg: okay, we'll need to look into the proper way of squashing root priv's with apparmor/selinux
[18:51] <rtg> kirkland: that seems like the right approach.
[18:52] <kirkland> rtg: okay, i'll confer that over, thanks for the sounding-board
[18:52] <rtg> kirkland: in fact, its likely the same problem the folks at the NSA tried to solve with SELinux. They didn't want their admins looking at security stuff.
[18:52] <kirkland> rtg: yup
[18:54] <kirkland> mhalcrow: rtg and I talked this over, and we don't think this is going to gain us anything over DAC (as you mentioned)
[18:54] <kirkland> mhalcrow: other than basically being able to specify the DAC at mount time
[18:54] <kirkland> mhalcrow: and not worrying so much about file/dir permissions
[18:54] <mhalcrow> Right. It would just be a lazy way to apply blanket dac on the mount.
[18:55] <kirkland> rtg: do you see any value to that?
[18:55] <mhalcrow> I have always had a policy of not introducing redundant access control, because that tends to increase complexity and opportunities for unintended consequences.
[18:56] <rtg> kirkland, mhalcrow: seems like a false sense of security to me. really, this is an issue on a multi-user machine, so we need a bigger hammer then just UID protection.
[18:56] <mhalcrow> Keyring perms, ugo/rwx, capabilities, and SELinux provide everything you need for any access control model you have in mind.
[18:58] <rtg> mhalcrow: ok, then the current ecryptfs solution using SELinux is sufficient to prevent root snooping, correct?
[18:58] <mhalcrow> Correct.
[18:58] <mhalcrow> Keys can be labeled.
[18:58] <rtg> I'm good with that.
[18:58] <mhalcrow> And eCryptfs passes through lower xattr's
[18:58] <mhalcrow> So the label on the lower file propagates to the eCryptfs mount.
[18:59] <rtg> kirkland: so the SELinux ball is in your court. I assume this is something you'll have to add to ecryptfs-utils?
[18:59] <kirkland> mhalcrow: do you know if anyone's worked with ecryptfs+AppArmor?
[18:59] <mhalcrow> Seems trivially circumventable with a --bind mount, but I'd have to look more closely at AppArmor for eCryptfs mounts.
[19:00] <kirkland> rtg: sure, i'll take that one.  no promises that i'll solve the root-snoop problem by Intrepid, but i'll keep working it
[20:16] <leche> hey, i found a bug in the kernel, which was allrdy fixed and confirmed by the devs of lm-sensors. Hows the procedure, to get this into the ubuntu kernel?
[20:17] <mjg59> leche: What's the bug?
[20:18] <leche> mjg59: http://rafb.net/p/VAgiQx37.html
[20:19] <mjg59> leche: Ok. File a bug on launchpad.net, attach that patch and include a pointer to the upstream discussion thread.
[20:20] <leche> ok, thx
[20:32] <leche> mjg59: https://bugs.launchpad.net/ubuntu/+bug/242761 is the description complete or is something missing?
[20:34] <rtg> leche: its fine
[20:34] <mjg59> leche: Looks ok
[20:34] <leche> what do you mean with upstream discussion thread?
[20:36] <mjg59> Ideally a link to the thread where it was discussed
[20:36] <rtg> leche: what mjg59 means, was there any discussion of this patch on LKML? If so, then include a pointer to the start of the discussion.
[20:37] <leche> rtg: no there wasnt, this was solved in irc and the lm-sensors mailing list
[20:38] <rtg> leche: I thought as much. the patch looks reasonable and straightforward, so its not controversial.
[20:39] <leche> rtg: ok, whats the procedure now? im just asking cause im interested
[20:40] <rtg> leche: it'll eventually show up as an SRU request. The kernel won't be out much before mid-July.
[20:40] <leche> thats good to hear, so i dont have to apt-pin the actual kernel
[20:41] <leche> thx guys
[20:41] <rtg> leche: it will also be on my PPA by tomorrow morning. http://ppa.launchpad.net/timg-tpi/ubuntu
[20:43] <leche> thx alot guys