[00:00] You'd want a pretty definitive case before going to court [00:00] makes sense [00:00] plus, it would ripple all over the place [00:00] kernel headers in glibc (LGPL) come to mind === cjwatson_ is now known as cjwatson === thegodfather is now known as fabbione === asac_ is now known as asac [13:45] hi, you did not add gspca yet [13:45] when will you do so for 2.6.26 [14:17] Kano: when we get to it [14:17] really, asking us questions like that is like trying to predict the weather [14:17] well the driver works, should be really easy to add [14:18] Kano: It will get done, just priorities is all [17:33] rtg: i see you have committed a fix for https://bugs.edge.launchpad.net/ubuntu/+source/linux/+bug/242448 [17:33] rtg: is there a kernel built that I can install/test this? [17:37] kirkland: not yet. I'll upload to my PPA and get it built today. [17:37] rtg: cool, update that bug with a pointer to your PPA. myself and hallyn are willing to verify the fix for you. [17:37] rtg: we're both subscribed [17:38] kirkland: it'll likely take a few hours. [17:38] rtg: that's fine... no rush, whenever [17:38] 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] 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] rtg: i think you were asking about something like this earlier [17:39] kirkland: which addresses my concern about root visibility on multi-user machines? [17:39] rtg: yup [17:40] 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] rtg: i'm hoping he'll get something like this into mainline soon.... [17:41] rtg: are we sticking with 2.6.26 for intrepid? [17:41] kirkland: 2.6.26 is the target version [17:42] kirkland: of course, we can cherry-pick some upstream fixes like this one. [17:42] rtg: that's sort of what i was asking [17:42] rtg: okay, let's see it get upstream first [17:46] 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] rtg: yeah, this idea spun off the "root_squash" idea, and is intended to be even more specific [17:48] rtg: but as you say, root can change his uid..... [17:48] kirkland: while this mount option would keep other users out, it only makes it slightly more difficult for root to go snooping. [17:48] rtg: true... hmm, ultimately, this should be key-based [17:50] 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] rtg: well, there's certainly an SELinux approach [17:51] rtg: add some SELinux hooks to ecryptfs is a long term goal of the ecryptfs developers [17:51] rtg: but that's non-trivial, IIUC [17:52] rtg: i'm not sure about AppArmor or SMACK [18:22] rtg: you'll get a kick out of this.... [18:22] rtg: -> mhalcrow: could we prevent root from running a script as that user and accessing the data? [18:22] Yes. It's called SE Linux [18:23] kirkland: well, I guess that makes sense :) [18:23] rtg: If you don't want root to be root, that's what you really need. [18:25] label based security does things path based security can't [18:45] 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] 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] rtg: true for unprivileged users, but that can be handled just by normal DAC, chmod +700 [18:48] kirkland: is that the default mount permissions? [18:48] rtg: not a mount issue; ownership on the mountpoint/device itself [18:48] kirkland: right, thats what I meant [18:49] kirkland: so, unless there is a good use case, it doesn't seem that worthwhile. [18:50] rtg: okay, we'll need to look into the proper way of squashing root priv's with apparmor/selinux [18:51] kirkland: that seems like the right approach. [18:52] rtg: okay, i'll confer that over, thanks for the sounding-board [18:52] 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] rtg: yup [18:54] 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] mhalcrow: other than basically being able to specify the DAC at mount time [18:54] mhalcrow: and not worrying so much about file/dir permissions [18:54] Right. It would just be a lazy way to apply blanket dac on the mount. [18:55] rtg: do you see any value to that? [18:55] 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] 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] Keyring perms, ugo/rwx, capabilities, and SELinux provide everything you need for any access control model you have in mind. [18:58] mhalcrow: ok, then the current ecryptfs solution using SELinux is sufficient to prevent root snooping, correct? [18:58] Correct. [18:58] Keys can be labeled. [18:58] I'm good with that. [18:58] And eCryptfs passes through lower xattr's [18:58] So the label on the lower file propagates to the eCryptfs mount. [18:59] kirkland: so the SELinux ball is in your court. I assume this is something you'll have to add to ecryptfs-utils? [18:59] mhalcrow: do you know if anyone's worked with ecryptfs+AppArmor? [18:59] Seems trivially circumventable with a --bind mount, but I'd have to look more closely at AppArmor for eCryptfs mounts. [19:00] 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] 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] leche: What's the bug? [20:18] mjg59: http://rafb.net/p/VAgiQx37.html [20:19] leche: Ok. File a bug on launchpad.net, attach that patch and include a pointer to the upstream discussion thread. [20:20] ok, thx [20:32] mjg59: https://bugs.launchpad.net/ubuntu/+bug/242761 is the description complete or is something missing? [20:34] leche: its fine [20:34] leche: Looks ok [20:34] what do you mean with upstream discussion thread? [20:36] Ideally a link to the thread where it was discussed [20:36] 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] rtg: no there wasnt, this was solved in irc and the lm-sensors mailing list [20:38] leche: I thought as much. the patch looks reasonable and straightforward, so its not controversial. [20:39] rtg: ok, whats the procedure now? im just asking cause im interested [20:40] leche: it'll eventually show up as an SRU request. The kernel won't be out much before mid-July. [20:40] thats good to hear, so i dont have to apt-pin the actual kernel [20:41] thx guys [20:41] leche: it will also be on my PPA by tomorrow morning. http://ppa.launchpad.net/timg-tpi/ubuntu [20:43] thx alot guys === rikai_ is now known as rikai