[00:24] <slangasek> superm1: are you sure media-retriever/mountmedia aren't in the initramfs?
[00:25] <slangasek> superm1: media-retriever should be included in all cdrom initramfses, according to the d-i source
[00:30] <TheMuso> slangasek: have livefs builds for powerpc been turned off, or are they dying in another way that I can't see, as I don't see any logs since Feb 27th.
[00:30] <TheMuso> livefs builds for ports in general actually.
[00:30] <slangasek> TheMuso: ports CD builds have been disabled because ports.u.c was having Issues, and the ports builds were both causing contention on the mirror while it was trying to repair its RAID array, and also breaking the non-ports builds due to locking issues
[00:31] <slangasek> I'll check with IS whether it's safe to re-enable
[00:31] <TheMuso> slangasek: ok thanks for that.
[03:46] <jdong> any X deities know why compiz trying to start on my jaunty Intel GMA950 would instantly lock up the system?
[04:38] <superm1> slangasek, i'll verify on monday. this came about because i was attempting to use a patched media-retriever so i didn't realize i'd have to repack the initramfs to use it.
[06:21] <jdong> sbeattie: http://jdong.mit.edu/~jdong/jailbuddy2.png this is what came of our discussion the other day :)
[06:21] <jdong> it's an ugly solution but it works
[06:21] <jdong> at least that gives some user interaction for willingly escaping out of apparmor
[06:21] <jdong> I will eat my hat if /usr/bin/file becomes vulnerable to some untrusted input exploit :)
[06:22] <jdong> (actually... that has probably happened before)
[06:27] <LaserJock> jdong: what kind of hat do you wear?
[06:27] <jdong> not a fedora ;-)
[06:28] <LaserJock> an edible hat might be nice
[06:33] <slangasek> superm1: aha
[08:51] <kees> doko: openjdk looks good with stack/fortify.  2 new errors, 1 fixed error, out of almost 3300 tests.
[09:44] <ion_> Woot, grub2 works.
[10:29] <ideamonk_> http://i39.tinypic.com/14cd4xi.png
[10:29] <ideamonk_> isn't the file selection windows too wide there
[10:30] <ideamonk_> imagine if a upload popup wished to allow users any one ".abc,.abd..... 60 such things
[10:30] <ideamonk_> won't that fill up all my screen space ?
[10:30] <ideamonk_> i've proposed a solution - http://ideamonk.blogspot.com/2009/03/trying-to-make-ubuntu-better.html
[10:31] <ideamonk_> i wonder if that window is handled totally by firefox or gnome makes it for the user
[10:31] <ideamonk_> any ideas ?
[11:12] <maxb> TheMuso: My audio was glitching horribly, your PPA packages fixed it up nicely. Is there any testing I can do to help with getting Jaunty's official audio fixed?
[11:22] <Laney> related, where would a bug where my master volume always resets to muted after login go?
[11:22] <hyperair> Laney: how about the init-scripts
[11:22] <Laney> really?
[11:22] <hyperair> Laney: one of the alsa ones
[11:23] <hyperair> Laney: it's supposed to save your volume when stop is called, and restore when start is called
[11:23] <hyperair> Laney: i noticed this in archlinux. probably is the same on debian-based systems
[11:23] <Laney> right, I never know what's pulse and what's alsa
[11:23] <hyperair> hahah
[11:24] <hyperair> pulseaudio is purely userspace
[11:24] <hyperair> whereas alsa has stuff both in kernelspace and userspace
[11:24] <Laney> but it has something to do with volume controls
[11:24] <hyperair> that's the way i understand it
[11:24] <hyperair> pulseaudio doesn't attack your volume controls on its own unless i'm mistaken
[11:24] <hyperair> as in the system's volume control
[11:24] <hyperair> individual apps yes, but not the system's volume control
[11:25] <hyperair> the system's one is handled by the alsa initscript
[11:25] <hyperair> erm alsasound
[11:25] <hyperair> /etc/init.d/alsasound
[11:25] <hyperair> it saves into /etc/asound.state
[11:25] <hyperair> and restores from there
[11:26] <Laney> I don't even have that file
[11:26] <Laney> the initscript, that is
[11:26] <hyperair> eh?
[11:26] <hyperair> lemme do a dpkg -S
[11:27] <hyperair> okay, thisi s strange, i can't find it
[11:27] <cjwatson> ISTR a bug being filed about this already
[11:27] <cjwatson> /etc/init.d/alsa-utils, BTW
[11:27] <hyperair> hmm? does that poke asound.state?
[11:28] <Laney> cjwatson: Cool, I was just trying to find the right places to search
[11:28] <hyperair> oh it does!
[11:28] <cjwatson> via alsactl, yes
[11:28] <hyperair> /var/lib/alsa/asound.state
[11:29] <Laney> bug 227505
[11:38] <geser> jdstrand: re bug 337659: where did you find the dependency? I see bmpx only listed in recommends with two other alternatives.
[12:20] <chris-p> pulseaudio on Jaunty is very stuttery
[12:21] <chris-p> did a test and: Underruns for  pulse:   26, Underruns for   alsa:    1
[12:47] <directhex> is cdimage down for everyone, or just me?
[12:49] <StevenK> http://downforeveryoneorjustme.com/cdimage.ubuntu.com
[12:50] <directhex> poot.
[12:50] <directhex> well, i'll use an intrepid cd & upgrade
[12:51] <sebner> StevenK: lol, cool site
[12:51] <chris-p> directhex: why not download it off a different mirror
[12:51] <directhex> chris-p, there arfe mirrors for jaunty discs?
[12:52] <chris-p> directhex: http://ftp.heanet.ie/mirrors/ubuntu-cdimage/releases/9.04/alpha-5/
[12:52] <directhex> oh, those crazy irish. woo!
[12:53] <elmo> maswan also has a mirror
[12:53] <elmo> in any event, I've kicked some of the worst offenders off of cdimage, and it's backup
[12:53] <directhex> i should poke the mirror.ox.ac.uk people
[12:58] <hyperair> directhex: down for me. it was up 6 minutes ago
[12:58] <hyperair> *5
[12:59] <hyperair> ah it's back up
[12:59] <directhex> i'll just wait for heanet's sloooow download
[13:08] <directhex> doko, thanks for ironpython upload in sid
[13:21] <Laney> anyone able to NEW pywebkitgtk binaries pretty please?
[13:22] <DktrKranz> Riddell, if you have time, mind looking at bug 334121 with your motu-release delegate hat on?
[13:26] <sebner> DktrKranz: nahh, kde is evil :P
[13:26] <DktrKranz> hey sebner!
[14:03] <jdstrand> geser: I see now that you are right. it is a Recommends only. script output didn't make that difference. my bad. I'll remove
[14:07] <jdstrand> geser: done
[14:10] <chris-p> directhex: download finished yet?
[14:54] <directhex> chris-p, oh, yeah
[15:14] <RainCT> pitti: about bug #338279, $GDMSESSION is "default" here, so the "if [ $GDMSESSION = gnome ]; then exec" won't work
[16:23] <ScottK> DktrKranz: Riddell is at a free software conference in Nigeria, so probably not for a few days.
[16:25] <DktrKranz> ScottK, oh, I didn't know that, thanks
[17:00] <Laney> doko: Would it be a problem for boost to depends on all of the pythonx.y-dev packages as alternatives?
[17:00] <Laney> libboost-pythonfoo-dev, that is
[18:06] <darksmoke> is there a way to install firefox on kubuntu without the list of unneeded-dontknow-why-they-where-added-as-dependencies dependencies?
[18:06] <darksmoke> like synaptics and suck
[18:06] <darksmoke> *such
[18:09] <azeem> darksmoke: that's a question for #ubuntu
[18:11] <directhex> azeem, or even for #kubuntu!
[18:16] <Toobaz> is there an Ubuntu official policy about packages which only have a menu item in the Debian menu (and hence end up in "Others" section)? I've asked a maintainer to add a .desktop under "Education;Science;Math;", but (also because of the bug that Science is no main cathegory) he prefers "Applications/Science/Data Analysis", and I can understand him. Is there any possibility to avoid a (quite permanent) patch at the M
[18:17] <Toobaz> (reference: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=518596
[18:19] <Toobaz> well, maybe #motu is the right channel, I move there, please forget my question here
[20:00] <Adri2000> slangasek: now that the samba sru is uploaded, can you approve it on behalf of ubuntu-sru please? (#328874)
[22:05] <lfaraone> Would it be reasonable to add apparmor profiles to userland SSH in jaunty+1?
[22:12] <jdong> lfaraone: do you have samples of what those profiles would look like?
[22:12] <jdong> I assume you have some change_hat patching for openssh
[22:16] <lfaraone> jdong: no clue, I'm not too familiar with openssh yet.
[22:16] <jdong> lfaraone: well the fundamental problem is Apparmor alone is not really granular enough to encapsulate openssh's role
[22:17] <jdong> lfaraone: in effect you need to allow openssh touch enough of pam and uid switching that it is probably going to end up not any more constricted than otherwise
[22:17] <jdong> at least that was my experience with attempting to secure it with apparmor
[22:17] <lfaraone> jdong: is there a way to make it that the only app that is allowed access to ~/.ssh is /usr/bin/ssh?
[22:17] <jdong> no.
[22:18] <jdong> apparmor is not good for doing system-wide restrictions like that
[22:18] <jdong> that's much easier to express in SELinux
[22:18] <lfaraone> jdong: why was apparmor chosen over selinux?
[22:18] <lfaraone> (I was juuust going to say, lol)
[22:18] <jdong> lfaraone: lack of intrusiveness, low overhead, simplicity of configuring
[22:19] <lfaraone> jdong: is there a way to improve apparmor in order to make it easier to implement system-wide restrictions?
[22:19] <jdong> lfaraone: it's not designed to do that I am afraid.
[22:20] <jdong> to clarify on "simplicity"
[22:20] <jdong> here's my irssi profile in apparmor for Hardy: http://paste.ubuntu.com/127980/
[22:20] <jdong> and here's the same thing in SELinux for Lenny: http://jdong.mit.edu/~jdong/selinux/irssi.if
[22:20] <jdong> the former I can explain to my 9 year old sister :)
[22:21] <lfaraone> jdong: hehe, because you hide all the scary bits in templates, I assume? :)
[22:21] <lfaraone> *include files
[22:21] <jdong> lfaraone: not at all
[22:21] <jdong> lfaraone: most of those bits are not required
[22:21] <jdong> lfaraone: note that SELinux is all in templates too
[22:21] <maco> at some point i have to learn to read that, and then to write it myself
[22:21] <jdong> i.e. corenet, corecmd, manage_*_pattern
[22:21] <jdong> userdom_*
[22:21] <lfaraone> maco: what, SELinux?
[22:22] <maco> lfaraone: yeah
[22:22] <jdong> in practice it's not IMO any more *difficult* to configure
[22:22] <lfaraone> maco: god, I'm going to kill myself if I end up managing RHEL systems; at least until they simplify that.
[22:22] <jdong> just the learning curve is a step function
[22:22] <lfaraone> jdong: is there a gui? :)
[22:22] <maco> lfaraone: why would you have a gui on a server?
[22:23] <maco> lfaraone: and RHEL includes some default contexts pre-configured, i think
[22:23] <jdong> lfaraone: not for either, in practice.
[22:23] <lfaraone> maco: yeah, I know.
[22:23] <jdong> there are some automated tools in GUI and CLI form for developing policies but none of them work in practice for me
[22:23] <lfaraone> maco: I mean for use on the desktop.
[22:23] <lfaraone> jdong: that's terrible.
[22:23] <lfaraone> maco: as in, I write a policy on my nice desky and scp it to the server.
[22:23] <jdong> audit2allow (SELinux) tends to suggest all the wrong things to do (i.e. give unconfined access, comeon do it! do it!)
[22:24] <lfaraone> jdong: unconfined? (you can tell I'm new to this)
[22:24] <jdong> and aa-logprof is equally unclear in asking a bazillion questions for something one glob accesses.
[22:24] <jdong> lfaraone: i.e. if irssi tries to read ~/.irssi and you haven't configured it to allow this
[22:24] <jdong> and then you run audit2allow
[22:25] <jdong> the deafult rule it generates is "read_files_pattern($1_irssi_t, $1_home_t, $1_home_t)
[22:25] <jdong> and similar for write files
[22:25] <jdong> which gives irssi full access to your unlabeled sections of your home directory
[22:25] <jdong> the "correct" pattern would have been to create a file context globbing the areas it tried to access if they were a general label
[22:26] <jdong> IMO neither of these tools NEED a GUI.
[22:26] <jdong> the hardest part is describing what your process to confine needs access to.
[22:27] <jdong> and if you can explain that to me in English, you can write it in selinux or apparmor just as easily
[22:27] <jdong> especially apparmor.
[22:27] <lfaraone> jdong: Well, AppArmor seems simple enough.
[22:27] <lfaraone> jdong: however SELinux seems unreadable to me.
[22:28] <jdong> lfaraone: it's a much more powerful system capable fo expressing far more relationships than an ACL.
[22:28] <jdong> it's necessarily complex.
[22:28] <jdong> hence it is capable of doing the OpenSSH profiles and GnuPG profiles you wanted :)
[22:29] <lfaraone> jdong: it is possible to have complexity while retaining ease of understanding and use, no?
[22:29] <jdong> lfaraone: not really
[22:29] <jdong> lfaraone: the apparmor language cannot define domains and file types between domains.
[22:29] <jdong> and that's fundamentally one of the things SELinux lets you do that makes possible the things you are asking for
[22:30] <jdong> and also, when SELinux "breaks" even your unconfined users are affected.
[22:30] <jdong> there are things that unconfined_u cannot do, and there's more of those when your policy is broken!
[22:31] <jdong> and I still haven't begun to understand how SELinuxing GUI apps correctly works :)
[22:32] <lfaraone> hm.
[22:32] <lfaraone> jdong: has any thought been put into using the rainbow/bitfrost framework for GUI apps?
[22:33] <lfaraone> jdong: OLPC did a pretty good job with the XO, with a (IMHO) very good framework.
[22:34] <jdong> lfaraone: what does bitfrost do in terms of domain-to-domain interaction though?
[22:34] <jdong> I recall it seemed to have next to NO protection for things that "interact with the home directory"
[22:34] <lfaraone> jdong: domain-to-domain?
[22:34] <lfaraone> jdong: you can't write to ~ at all, hehe.
[22:34] <jdong> lfaraone: Firefox needs to save a file you download, and then open it with Evince.
[22:34] <lfaraone> jdong: since each app is technically running as its own user.
[22:34] <jdong> how do you implement that with a bitfrost setup?
[22:35] <jdong> like with Apparmor it's a relationship that's pertty freaking hard to describe.
[22:35] <lfaraone> jdong: currently we have firefox save an object to the journal (which is a problem once you are talking about non-abstract file structures), and you're sent to the object's details page where you choose to open it in evince.
[22:36] <LaserJock> lfaraone: btw, how is Abiword going?
[22:36] <jdong> sounds as hackish as my apparmor solution.
[22:36] <jdong> http://jdong.mit.edu/~jdong/jailbuddy2.png
[22:36] <lfaraone> LaserJock: it isn't, I was hopelessly lost. I *think* morgs was working on it,
[22:36] <lfaraone> *.
[22:37] <jdong> someone told me yesterday jail buddy reminded them of UAC :(
[22:37] <LaserJock> k
[22:37] <lfaraone> jdong: hehe
[22:37] <lfaraone> jdong: it's like that, but in OLPC/sugar we're intergrating it with the whole UI paradigm so it's unintrusive (assuming you don't expect computers to work the way Windows/GNOME/KDE does)
[22:38] <jdong> lfaraone: one of my longer term projects is working on a Firefox SELinux profile that supports the concept of quarantined files the way OS X handles them
[22:38] <LaserJock> jdong: shouldn't that be called JailFileKit or similar? :-)
[22:38] <jdong> i.e. they are labeled in such a way that the user is neither allowed to access nor execute them until "bringing it out of quarantine"
[22:38] <lfaraone> jdong: interesting
[22:39] <jdong> lfaraone: how does bitfrost deal with local priviledge escalation once an app is compromised?
[22:39] <jdong> lfaraone: i.e. if I took advantage of that flashplayer 0day and had a shell within Firefox, what can I do?
[22:48] <lfaraone> jdong: anything firefox can do , which is steal your cookies.
[22:48] <lfaraone> jdong: write huuuuuge files to the journal (currently nothing stops you from doing that)
[22:48] <lfaraone> jdong: and nothing else. you cannot su, etc.
[22:48] <lfaraone> jdong: you can only see things that you have been explitly given access to by a user action.
[22:50] <lfaraone> jdong: and steal your banking info.
[22:50] <lfaraone> jdong: however it's isolated; unless you are able to exploit another app you can't spread to it.
[22:51] <lfaraone> jdong: (ie if I write shell code to the journal, the user has to exec it manually)
[22:53] <jdong> lfaraone: how is the process space divided? can I ptrace() existing processes or peer into /proc or /sys?
[22:53] <jdong> flashplugin definitely requires access to /proc to work correctly.
[22:54] <TheMuso> maxb: Talk to dtchen when he is online, he is trying to get glitchy issues sorted out.
[23:23] <lfaraone> jdong: would it be a problem if you were? I think you *can*, currently.
[23:24] <jdong> lfaraone: well yes in a way it would be
[23:25] <lfaraone> jdong: how exactly?
[23:25] <jdong> lfaraone: a few of the root level kernel exploits were done through malformed proc/sys not to mention seeing what processes are running can be a serious privacy breach.
[23:25] <jdong> it still doesn't stop me from abusing your firefox into a free-for-all worm/zombie spam server
[23:25] <lfaraone> jdong: does SELinux?
[23:25] <jdong> yes.
[23:26] <jdong> 18:26 Exec: /bin/sh: Permission denied
[23:26] <jdong> 18:26 -!- Irssi: process 0 (ls) terminated with return code 255
[23:26] <jdong> jdong@CLOSETMONSTER:~$ ps aux | wc -l
[23:26] <jdong> 4
[23:26] <jdong> I think there's more than 4 processes running on my system ;-)
[23:26] <jdong> jdong@CLOSETMONSTER:~$ su -
[23:26] <jdong> Password:
[23:26] <jdong> ls: cannot access /root: Permission denied
[23:27] <jdong> ls: cannot open directory /home/jdong: Permission denied
[23:28] <jdong> su'ing to root actually ended in a useless context that had access to neither root's home nor the original user's home :)
[23:37] <lfaraone> jdong: 18:32  m_stone$ lfaraone: you can ptrace() processes running as your same uid.
[23:37] <lfaraone> jdong: lol. I already told you, though, that /bin/su isn't executable by the world.
[23:38] <lfaraone> jdong: (in our magic rainbow situation)
[23:43] <jdong> lfaraone: but that doesn't preclude a root exploit being leveraged via another means -- you provide basically any Linux ability that your jail environment has, and as you get domains to interact with each other (which FRANKLY in the current setup -- they CAN'T) it's going to get harder and harder to balance security and intrusiveness.
[23:43] <jdong> IMO it's not a good replacement for something like the UBAC SELinux refpolicy that was just checked in @ tresys
[23:44] <lfaraone> jdong: oh yes, we're most surely going to persue a system where rainbow and SELinux complement each other.
[23:45] <lfaraone> jdong: RH sent over some of their own engineers, and even the "selinux people" couldn't think of how to make selinux do what we were trying to accomplish.
[23:46] <jdong> well indeed SELinux is not the magic bullet for this stuff either.