PowerUserApplet

  • Launchpad entry: none yet

  • Created: 2006-07-04 by JohnMoser

  • Contributors: JohnMoser

  • Packages affected:

Summary

We aim to define a set of power user tasks to tweak Ubuntu for security, performance, and other needs.

Rationale

There's a lot of nice stuff people should be able to do without being world-class hackers. Understanding the idea of process limits for example is easy enough, and this idea should be useful without having to dig for /etc/security/limits.conf

Use cases

There are many use cases possible.

  • A power-user may explore and find out about process limits, and want to tweak these without hacking limits.conf
  • A typical user may be instructed by a friend to tweak vm.swappiness
  • We may have interesting features that we do not want to enable by default just yet, such as tmpfs on /tmp.

Scope

Our scope is anything and everything, but in a modular fashion.

Security:

  • PAM controls
    • libpam-cracklib configuration
      • Enable strong password enforcement
      • Configure minimum password length
      • Configure number of new characters in the new password (difok=)
      • Configure password credit mode, defining how to handle Upper Case (A), Lower Case (a), Numeric (1), and Special Characters (#).
        • Credit: Count only N of each type of character for password length. For example, with A/a/1/# = 2/2/2/3, AAAaaa1### would count as an 8 character password.
        • Minimum: Require at least N of each type of character in the password. A password with A/a/1/# = 2/2/2/2 would be AAaa11##, but Aa11##@@!!! would not work.
    • libpam-opie configuration
      • Enable and generate one-time pads
      • Allow regeneration and reprinting of new one-time pads
    • libpam-tmpdir
      • Allow tempfile directory to be changed, granting extra security!
    • libpam-umask
      • Allow adjustment of the default umask. 0700 is a good, tight umask; 0755 is a more open one (and our default).
    • libpam-mkhomedir
      • Allow automatic creation of home directories
      • Follow this one after libpam-umask so it gets the proper permissions
  • Limit controls
    • Configure /etc/security/limits.conf for pam_limits
    • Configure settings per-user and per-group similar to the users-admin applet
  • Default group
    • Put users in group 'users' instead of group $USERNAME

Memory:

  • Swappiness: tweak vm.swappiness

Network:

  • Syn cookies: Enable TCP syn cookies
  • RFC1337: Enable RFC1337 security features

Design

The power user applet should be a modular configuration applet.

  • Configuration applet, like network-admin.
  • Completely modular, loading plug-ins from /usr/lib/poweruserapplet/
  • Plug-Ins define types of settings, groupings, and callbacks made
  • Applet draws the controls (sliders, checkboxes, buttons)
  • We may produce a KDE and GTK+ version using the same plug-ins, for Kubuntu and X/Ubuntu

Implementation

Code

Data preservation and migration

None yet.

Unresolved issues

  • There's a lot more we can tweak

Comments from Mark

This place looks about right for my comments. They concern init scripts, tmpfs, fstab, and swap. I hope they become official specifications. Some may relate to the "power app" but most relate to basic system architecture.

Feisty Boot Testing

Please test Feisty bootup under RAM-based configurations. That means tmpfs and/or no swap space. Ubuntu Dapper works with

tmpfs /var/run tmpfs rw 0 0

tmpfs /var/lock tmpfs rw 0 0

but fails with /var/log and /tmp mounted tmpfs. The reason is usually because init script XYZ assumes folder /var/log/XYZ or /tmp/XYZ persists across boots.

The patch is simple and obvious: every init script should test for, and if necessary generate, subdirectories it needs, prior to main execution. This is just defensive coding. Some init scripts at low runlevels and high boot priority have such bugs. Which ones vary by Linux distribution. (I am aware that /var/tmp is intended to persist on disk, but even that should work if mounted tmpfs, though you could defer that spec.)

  • I use tmpfs on /tmp here; /var/log should not be a tmpfs because the logs need to persist for record keeping. Would you like to see your syslog get wiped after a kernel panic? How about only having Web server logs since the last reboot (this will break stats rendering)?
  • (Mark:) Usage cases exist for which disk logs make sense. Other cases exist for which they don't. My users need speed and security over debugging capability. “Record keeping” is a security breach for “borrowed” laptops. Users never debug. That takes place at my office and my job is tailoring systems for their everyday needs, not making rare debugging simpler for myself.

Performance Tuning for tmpfs

Disk I/O is a major performance determinant. Constant access to /tmp and /var/log hurts. Moving them to RAM makes systems faster. These folders can also jeopardize security (e.g. log files) or just clog disks over time. Tmpfs makes systems faster and keeps them clean.

  • Logs need to persist across reboot. They exist for a reason.
  • (Mark:) See above. More reasons on my side: laptop battery life, minimizing writes to usb flash

Tmpfs lacks a wholesale tuning parameter. Fstab can limit each mount individually (size=X), but not all collectively. Debian source implements a hard-wired divide-RAM-by-two constant. That value should be parametric from fstab or some other place.

  • Linux uses half of RAM as a default, size tunes it.
  • (Mark:) That was the point. Size tunes one tmpfs mount. You need to set each one by hand using some rationale. A parametric limit on all tmpfs across all mounts is better. It requires less expertise to tune and serves more usage cases generally.

The advantage is ease of use plus flexibility. Putting limits on each mount individually requires expert knowledge. Even where available, that only works for one usage scenario; there can be many. A general limit will work in all cases. Most users don't know how much /var/log needs, but do know how much RAM consumption they will tolerate for junk before swapping it all to disk.

Half of RAM is a lot. People do not want that much RAM eaten by junk files. So a reasonable upper limit would be, say, 15% of RAM before tmpfs resorts to swap space, instead of today's arbitrary 50% setting. Ubuntu might use some other cap, but the point remains, there's no way to adjust it short of kernel recompilation.

  • Linux treats tmpfs as disk cache, except it gets swapped out instead of invalidated. Magical settings to make only half of RAM get eaten by tmpfs don't exist.

  • (Mark:) The magical setting http://lxr.linux.no/source/mm/shmem.c#L2074

Swap Not Always

Tmpfs should work even when no swap is available, in which case, it behaves like ramfs. Whatever limits fstab placed on it should still be respected.

  • This works already.

One can execute "swapoff -a" but Ubuntu should offer some way to configure that automatically for people with lots of RAM.

Noexec and Nosuid

Security: Miscellany temp folders should default noexec, nosuid. Developers are not running that way, so bugs creep in. A well known apt glitch needs this work-around for /etc/apt/apt.conf:

DPkg::Pre-Invoke {"mount -o remount,exec /tmp";};

DPkg::Post-Invoke {"mount -o remount /tmp";};

which should be the default in Ubuntu until such time as apt itself is fixed not to need execution from /tmp.

  • Scripts can be loaded by . ./script_name; ld.so ./binary_name doesn't work for executables because Linux won't allow execution of mmap() segments on no-exec mounts.

  • (Mark:) The patch works under Debian Etch for enormous installs like full GNOME and OpenOffice (apt-get install gnome-desktop-envionrment openoffice.org). It's not the final answer, i.e., securing apt/debs, but does work. See http://www.debian-administration.org/articles/418 for a recent, related exploit on /proc with the same fix as /tmp.

  • /var/tmp still typically resides on /
  • (Mark:) ...probably what apt/debs should use instead of /tmp, TBD.

BoF agenda and discussion

CategorySpec

PowerUserApplet (last edited 2008-08-06 16:31:22 by localhost)