Ubuntu

Bug #14166
Comment #3

Comment 3 for bug 14166

Revision history for this message

John Moser (nigelenki) wrote on 2005-04-25:

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 <XXX> 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.

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 <XXX> 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.