Re: Ubuntu Studio 11.10 Oneiric artwork brainstorming/discussion
On 25 May 2011 23:36, C K coryis...@gmail.com wrote: On Wed, May 25, 2011 at 6:09 PM, Izo designby...@gmail.com wrote: Name a time/date that is most convenient for you guys. =] @Scott: Sunday sometime? If you could provide me with the essentials on LightDM theming, that would be handy. I'm looking into that now. it's a PITA as LightDM doesnt work on Natty. Maybe there's a PPA with updated packages. Not *entirely* certain what you mean by the style of the AWN background. Could you point me to something you have in mind? Imagine a flat surface. Then you took something like a melon baller or ice cream scoop and scraped out a straight line using half of the scoop. I guess it would look like the shape of a pill, but cut in half. But that recess, that scoop is where icons would sit. I *hate* that this is the best example I can find in a pinch: http://planetiphones.thebigboss.org/repository/info/theme-images/apple-slider-preview.jpg Alternatively, we could do something that makes the dock look cut-through the wallpaper: http://www.marketwallpapers.com/wallpapers/19/wallpaper-109959.jpg Savy? -- -Cory K. -- Ubuntu-Studio-devel mailing list Ubuntu-Studio-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-studio-devel I'm good for Sunday, any time after 19.30GMT (15.30EST/12.30PST). Also, Cory, I see what you mean now regarding the dock background, I'll have to experiment with AWN theming again, it's been a while. - Izo -- Ubuntu-Studio-devel mailing list Ubuntu-Studio-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-studio-devel
Re: Ubuntu Studio 11.10 Oneiric artwork brainstorming/discussion
On Wed, May 25, 2011 at 9:49 AM, Izo designby...@gmail.com wrote: Right, think I'm about done with this now. This is how I, potentially at least, see the Ubuntu Studio Oneiric desktop. PLEASE NOTE: this isn't prescriptive, I'm not saying, This is DEFINITELY how the desktop should look, GET ON IT, I'm saying, in terms of an overarching look and feel, perhaps something like this is the way forward. By all means, give me your opinions and whatnot. Maybe you missed some details I laid out in previous emails. Generally, I wouldn't ship a wallpaper with branding. Especially one with it so central. Something subtle would possibly work. The UI is set. Working toward using only AWN at the bottom, or it doesn't work out, a single panel across the top copying our GNOME layout. I do still need to add some details to the wiki but between that and emails I thought things were clearer. I am open to the GTK theme ideas. Do you do any tinkering there Izo? In terms of over-arching look and feel, the plymouth, LightDM and wallpaper images are the things I'm looking to tie into the website really. I'm hoping for various revisions/ideas for the wallpaper. From that, many ideas can come. For instance: We could use the same base image for the LightDM and wallpaper, but the LightDM has branding and the desktop does not. So it appears to fade away. Based on this etched idea, I'll come up with some concepts. I'm off for the next 4 days. ;) Izo: Can you send me the source for the wallpaper? How's 20:00GMT for that meeting on Sunday? Scott? -- -Cory K. -- Ubuntu-Studio-devel mailing list Ubuntu-Studio-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-studio-devel
Re: Enabling the kernel's DMESG_RESTRICT feature
On Tue, May 24, 2011 at 11:46:48AM -0700, Kees Cook wrote: As we have continued to close kernel address leaks, the kernel syslog (dmesg) remains one of the last large places where information is being reported. As such, I want to close this off from regular users so that local kernel exploits continue to have an even harder time getting a foot-hold on vulnerabilities. And, as before, this is a tunable that you can change in /etc/sysctl.d/ if you do development work, like getting owned, etc. For the average user, this information is not needed. What are the ways in which kernel addresses are leaked through dmesg? Can you provide some examples? Is it not feasible to avoid leaking addresses, while still passing on all of the useful data in dmesg to users? -- - mdz -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Patch Pilot Report 2011-05-25
Am Donnerstag, den 26.05.2011, 09:45 -0400 schrieb Stéphane Graber: The following should be removed from the sponsor list: [...] All done except the following, because I can't change the status for it. https://code.launchpad.net/~smoser/ubuntu/natty/sudo/lp-768625/+merge/58762 (mvo uploaded to proposed) -- Benjamin Drung Debian Ubuntu Developer signature.asc Description: This is a digitally signed message part -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Enabling the kernel's DMESG_RESTRICT feature
Excerpts from Kees Cook's message of Wed May 25 10:01:12 -0700 2011: On Wed, May 25, 2011 at 08:07:14AM -0400, Scott Kitterman wrote: On Tuesday, May 24, 2011 06:00:17 PM Clint Byrum wrote: Excerpts from Kees Cook's message of Tue May 24 11:46:48 -0700 2011: One unresolved problem is that the local default user (who is part of admin) is also part of the adm group, which means these log files are visible without additional privileges: -rw-r- 1 root adm 25937 2011-05-24 10:59 /var/log/dmesg -rw-r- 1 syslog adm 0 2011-05-24 11:17 /var/log/kern.log (And some system have a historically world-readable /var/log/dmesg that should be fixed...) Does anyone see any problems in removing the default user from the adm group? It seems to almost exclusively only be used for log file reading permissions... Thoughts, flames, etc? +1 I've always been a bit surprised at how much I can see in /var/log when logged into a brand new box as the initial admin user. I think users are accustomed to sudo when debugging issues, and I'm comfortable with saying that reading /var/log/* is just one more thing you need to use sudo for. Clint, what do you think of the proposal below? It's a less dramatic change, which might be more well received ultimately. +1 for a less surprising and still quite effective way of achieving the goal. -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Enabling the kernel's DMESG_RESTRICT feature
On Wed, May 25, 2011 at 09:36:16PM +0200, Martin Pitt wrote: So if needed, you can implement attach_dmesg() with attach_root_command_outputs(). Ah, perfect. That'll be the way to go, then. But aside from that I do agree with Steve that it both seems a lot safer as well as more convenient and less intrusive to just filter out the address from the printk in the first place, instead of disallowing non-admins to see some useful debugging (like errors on removable disk drives, what the heck is currently wrong with their wifi, etc.) This just isn't going to happen, unfortunately. The number of leaks is giant, and upstream is completely unwilling to filter printk() so far. I wanted to get this turned on now because it will be needed once we have kernel base address randomization, and if that happens for the LTS, I didn't want to have to make the dmesg privilege transition also in LTS. -Kees -- Kees Cook Ubuntu Security Team -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Enabling the kernel's DMESG_RESTRICT feature
On Wed, May 25, 2011 at 09:37:47PM +0200, Martin Pitt wrote: Kees Cook [2011-05-25 12:05 -0700]: Currently, the upstream kernel folks have rejected filtering printk. That's not actually what I meant. Don't filter the outputs of printk() with some regexps. I meant just kill the printk() call that prints the address. Why would you even need to printk() it if the very thing it prints out is not meant to be seen in logs? Right. This is precisely what upstream has refused[1] to do. The problem is that dmesg is just a log. The contents can't be adjusted based on who is viewing it like (like has been done for the %pK sprintf uses in /proc, /sys, etc). Things like Oops reports will go to dmesg, which are utterly useless without all their addresses intact, etc. The only way to close this entire area of leaks is to make dmesg a privileged resource, and that is possible using the dmesg_restrict stuff (created for this very purpose). -Kees [1] http://marc.info/?l=linux-netdevm=128915072325450w=2 -- Kees Cook Ubuntu Security Team -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Enabling the kernel's DMESG_RESTRICT feature
On Wed, May 25, 2011 at 11:49:45AM -0700, Steve Langasek wrote: On Tue, May 24, 2011 at 11:46:48AM -0700, Kees Cook wrote: In Oneiric, I'd like to change the default availability of yet another long-standing system debugging feature: dmesg. I think this is a bridge too far. dmesg is a very important tool for debugging systems, and I am very concerned that this will impair my ability to troubleshoot kernel problems on my hardware - perhaps under circumstances where the system is so far gone that 'sudo' doesn't work. Which means I would probably have to twiddle the sysctl bit, which means I won't get the intended protections. If you are debugging a sudo failure, it's probably not the kernel's fault. :) If you just need to be root, you can reboot to single user and examine the kern.log file. If your disks are busted, you can reproduce after booting single user, etc. I won't say it doesn't complicate things, but I would like to point out that everyone else's suggestion for this is to completely remove the values from the dmesg report itself, rendering it unavailable to any user, even root. Systems that are misbehaving or under development can just always run with the dmesg_restrict bit off. A system that experiences a single unique failure where the kernel log can never be accessed seems like a very small corner-case to hold back a benefit to the rest of the distro's users. Kernel address leaks will become even more valuable to exploit authors once kernel base address randomization[4] lands in the kernel, and I want to make sure Ubuntu is prepared, well in advance of the next LTS, for this change. When the base address is randomized, dmesg must be privileged, or else the exactly offset is trivially visible (i.e. of the offset from 0xc100): $ dmesg | grep -m1 text [0.00] .text : 0xc100 - 0xc15112a1 (5188 kB) Why can't we simply change the kernel to not output this line when base address randomization is in use? I think I've covered this in other emails -- the leaks are intentional and useful for debugging. Losing them permanently is not sensible. One unresolved problem is that the local default user (who is part of admin) is also part of the adm group, which means these log files are visible without additional privileges: -rw-r- 1 root adm 25937 2011-05-24 10:59 /var/log/dmesg -rw-r- 1 syslog adm 0 2011-05-24 11:17 /var/log/kern.log (And some system have a historically world-readable /var/log/dmesg that should be fixed...) Does anyone see any problems in removing the default user from the adm group? It seems to almost exclusively only be used for log file reading permissions... Yes, this is a BIG problem. The adm group is there precisely so that admins don't have to use su/sudo and type a password to look at log files. If I'm trying to debug a Network Manager problem on a system that uses network-based authentication, not being in the adm group means I have to wait for network timeouts before I can look at the logs to figure out what I need to do to fix my network! Right, a fair point, and I think the better approach is what was suggested in another thread: just change these two files to group root. -Kees -- Kees Cook Ubuntu Security Team -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Patch Pilot Report 2011-05-25
Benjamin Drung [2011-05-26 18:48 +0200]: All done except the following, because I can't change the status for it. https://code.launchpad.net/~smoser/ubuntu/natty/sudo/lp-768625/+merge/58762 (mvo uploaded to proposed) Set to merged. Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) signature.asc Description: Digital signature -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Onscreen keyboard and dwelling in LightDM
Hello Robert, You might remember that I already opened a thread about onscreen keyboards, dwelling and display manager shortly before UDS-O. LightDM being the default display manager for Ubuntu 11.10, I would like to ask whether there is already a plan about integrating accessibility features into LightDM? In the following, I will restrict myself to the onscreen keyboard and dwelling part of the accessibility features, as these are the tools I know. In other words, I am only going to talk about people that can move the pointer, but are not able to use a hardware keyboard (pointer-only users); I do not have the necessary knowledge about access to the computer for switch users, visually impaired users, hearing impaired users, etc; thus I prefer leaving these topics to people with the corresponding knowledge. In fact, I think that accessibility is so diverse that it is best to have input from people of the different accessibility areas. As pointer-only users cannot use a hardware keyboard, they need a way to access the onscreen keyboard by using only the pointer. Moreover, there are pointer-only users that are not able to click with a hardware device. These users need a way to activate automatic click, also known as dwell click or hover click, by only moving the pointer to a determined area/spot of the screen and resting there for a little time. For users able to click, the solution is straightforward: simply add an item to the options/accessibility gui that the user can click to open the onscreen keyboard. For users not able to click, a dwellable spot, that enables dwelling is needed. What about using the options/accessibility item itself as the dwellable spot. It could for example work like this: The user moves the pointer to the options/accessibility item and some sort of bubble or notification area with a countdown appears. The bubble informs the user that if he moves the pointer to a specific area of the bubble, automatic clicking will be enabled. Advantages of this approach: - no additional exclusive dwellable spot is necessary - if the user does not react to the bubble, nothing happens - only one item has to be made dwellable in order to enable dwelling (*) Or course, it should remain possible to open the options/accessibility item as usual by a mouseclick. Ubuntu is shipping an onscreen keyboard and dwelling software since several releases with their default installation. Their names are onboard and mousetweaks and both of them do NOT require at-spi to run. So they can be started and used also when at-spi is not running. (*) Another approach would be to open the options/accessibility item after the timeout and add another dwellable item in the options/accessibility menu/dialog to start dwelling. Meanwhile, I think that marmuta's idea with the activation area in the bubble is superior, as it only needs one dwellable spot instead of two. (marmuta is part of the onboard devel team, Gerd is the coder of mousetweaks; both are getting a copy of this email.) The options/accessibility interface should not only provide a way to start the accessibility tools, but also to quit them. Regarding this, if I remember correctly, mousetweaks has a --login option; Gerd, please correct me if I am wrong. As far as I could read, LightDM aims to become a cross desktop display manager; thus, I suppose that it should also provide a way for distributions (and users) to replace an accessibility tool that provides a specific feature with another providing that feature; for example some distributions might want to replace the onscreen keyboard named onboard with the onscreen keyboard caribou or florence or even another one. Finally, I suppose that the options/accessibility part of LightDM is also a component of the greeter. Consequently, I wonder whether the persons designing the greeter for Ubuntu are in part the persons responsible for the addition of the options/accessibility items to the display manager? Is there anybody in particular that should also be contacted? Cheers, Francesco -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
