I'd hope the eventual program would look more like the Users and Groups app we have, or be an extension of said :) I was only doing the mock-up as a visual aid because I suck horribly at UI design. But here's some blowback: -General- You're right, on all of it. It generally sucks. -SetUID- * This tab would make more sense as a "Security" tab in the "Users and Groups" control panel. Additionally, a lot of this would make sense if you extended the control application to "Users, Groups, and Security," since Users and Groups are used effectively for access control, which is security. * Translate into english Yes. Do that, all of it. * If possible, combine "use 'at'" and "use cron" into a single option, "Set tasks to be performed at scheduled times". The 'at' program has its own separate implications from 'cron' -Accounts- * I have no idea what "BSD r-tools" are, and Google's no help. Explain. It was in bastille. I don't know what it was either. * Checkboxes aren't for determining whether something's off, Reverse the logic * "Restrict who can use cron" to ... what? Twas in bastille. Restrict it to users allowed to use cron :) * "Restrict default file permissions to user" what? This looks like an incomplete sentence. default umask should be 0700 instead of 0755 * Translate "Restrict root account to sudo only" into English. Again I can't help because I don't understand what this means. This we already do. You can't log in as root, only as a user with sudo access. Booting * Call it "Startup" instead. I prefer "boot" instead of "startup," because people need to get on the same page with the vocabulary. Better to learn what it's called, than to break it and go into a channel like "I can't get the boot to the computer and i need you to upload a new windows" (i've had that happen, I couldn't help the person at first because I couldn't understand wtf he was saying until 10 minutes of gibberish later). This isn't a huge barrier. * Use a header, "Ask for password before:", followed by checkboxes for "Starting up" and "Restarting". The password in the boot loader is to keep people from using custom startup settings, such as {scroll to menu entry, e, kernel line, e, init=/bin/sh} to get instant root access. Passwords for shutting down are to prevent people from shutting down of course. -Resources- * "No core files"? How is this a security feature? Explain, in the GUI. Core files are dumps of memory. A technician can fish out frobnicated (foo XOR 0x42424242) root passwords and credit card numbers and defrobnicate them easily. Also, core files accumulate and eat up space when things repetedly crash. This can cause a denial of service attack (full disk). Most users just leave these things laying around for lack of knowing or caring what they are. -PaX- * This tab is meaningless to someone who doesn't know what PaX is, which is most people. Explain, in the GUI. Yeah, and on non-PaX systems like default ubuntu, this will be meaningless. Eventulaly Ubuntu will support PaX. This configuration would need to be around to control it. This would include turning it on and off, and setting restrictions for individual programs, as well as grouping those restrictions together. Additional configurations per-package should be packaged with the programs. This should be somewhat similar to Microsoft's "Data Execution Prevention" configuration, but much more flexible. -GrSecurity- * I have no idea what any of the options in this tab do. Explain them, in the GUI, following the models given above. Yeah this is going to be more of a "You need to be a security technician" thing. I could explain it, but a normal user won't get what exactly any of it does without a real security background. -chroot()- * As for GrSecurity. The more admins can understand these options, the more useful they'll be. Much easier to get this one through. Usually you can tell why things are breaking, so if you explain these options they at least make sense to an administrator, "Cannot change time" "DIsallow changing time in chroot()" hmmm! -Stack Protection- * The ProPolice option would be best presented as: "When someone tries to break in to a program on your computer: (*) let them break in ( ) crash the program" That's a silly option, because both choices are horrible. So don't present the option. Actually, it depends. Breaking in is infinitely better than crashing if you're a business supplying a level of service and you house no confidential information (CI) on that computer. Most users will probably want "Crash the program" because it will cause a problem NOW, but that problem will go away. For example, maybe I'll lose my mozilla session (unless I have the SessionSaver extension); but I won't be infected with a worm that was coming through mozilla to eat all my documents. Also, in the future ProPolice (and LibSafe) could be altered so that with the flipping of a certain option, the crash could be linked to the delivery of information about the crash back to Ubuntu. The theory is that because the corruption prevents you from RETURNING from a function but NOT calling new ones, it's perfectly alright to continue to call new functions to deliver a chunk of information up to Ubuntu's devs to inform them of the crash, with limited data from the program. This of course means that the program must NOT deliver CI to Canonical in the process. * Explain, in the GUI, why I would ever want to have LibSafe off. Same issue as ProPolice, plus some performance that really won't be noticible. In conclusion: 1. You have a lot of good points and I find them agreeable. 2. I would rather keep the interface slightly technical; but you are correct in the conjecture that it should fully explain itself in a way a normal user can understand. Please make sure proper technical terms are used though. 3. Certain parts, no matter how well explained, are not going to tell the user if he should or should not disable the option simply because one program doesn't run. The risk managment involved in making security decisions requires a security technician. Nevertheless, the function should be explained well so that the user can identify that that option is probably causing the problem. 4. Certain parts will be specialized for certain enhanced kernels, especially the PaX and GrSecurity kernels. 5. This thing should probably be collapsed into the Users and Groups application as Users, Groups, and Security.