| 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 | 00:00 |
| === cjwatson_ is now known as cjwatson | ||
| === thegodfather is now known as fabbione | ||
| === asac_ is now known as asac | ||
| Kano | hi, you did not add gspca yet | 13:45 |
| Kano | when will you do so for 2.6.26 | 13:45 |
| 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:17 |
| BenC | Kano: It will get done, just priorities is all | 14:18 |
| 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:33 |
| 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:37 |
| 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:38 |
| 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:39 |
| 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:40 |
| 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:41 |
| 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:42 |
| 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:46 |
| 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:48 |
| 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:50 |
| 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:51 |
| kirkland | rtg: i'm not sure about AppArmor or SMACK | 17:52 |
| 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? | 18:22 |
| kirkland | <mhalcrow> Yes. It's called SE Linux | 18:22 |
| 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:23 |
| SEJeff | label based security does things path based security can't | 18:25 |
| 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:45 |
| 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:46 |
| kirkland | rtg: true for unprivileged users, but that can be handled just by normal DAC, chmod +700 | 18:47 |
| 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:48 |
| rtg | kirkland: so, unless there is a good use case, it doesn't seem that worthwhile. | 18:49 |
| kirkland | rtg: okay, we'll need to look into the proper way of squashing root priv's with apparmor/selinux | 18:50 |
| rtg | kirkland: that seems like the right approach. | 18:51 |
| 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:52 |
| 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:54 |
| 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:55 |
| 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:56 |
| 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:58 |
| 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. | 18:59 |
| 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 | 19:00 |
| 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:16 |
| mjg59 | leche: What's the bug? | 20:17 |
| leche | mjg59: http://rafb.net/p/VAgiQx37.html | 20:18 |
| mjg59 | leche: Ok. File a bug on launchpad.net, attach that patch and include a pointer to the upstream discussion thread. | 20:19 |
| leche | ok, thx | 20:20 |
| leche | mjg59: https://bugs.launchpad.net/ubuntu/+bug/242761 is the description complete or is something missing? | 20:32 |
| rtg | leche: its fine | 20:34 |
| mjg59 | leche: Looks ok | 20:34 |
| leche | what do you mean with upstream discussion thread? | 20:34 |
| 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:36 |
| leche | rtg: no there wasnt, this was solved in irc and the lm-sensors mailing list | 20:37 |
| rtg | leche: I thought as much. the patch looks reasonable and straightforward, so its not controversial. | 20:38 |
| leche | rtg: ok, whats the procedure now? im just asking cause im interested | 20:39 |
| 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:40 |
| 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:41 |
| leche | thx alot guys | 20:43 |
| === rikai_ is now known as rikai | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!