[kde-linux] Splash screen import errors
1i5t5.duncan at cox.net
Sat Jan 30 15:02:51 UTC 2010
Kevin Krammer posted on Sat, 30 Jan 2010 12:14:25 +0100 as excerpted:
> On Saturday, 2010-01-30, Duncan wrote:
>> Allows to specify another path than /tmp where KDE stores its temporary
>> (Actually, kde normally creates its own directory in /tmp, I believe
>> it's /tmp/kde-<user>/ , with <user> of course replaced appropriately,
>> for each user. More secure distributions may patch this to have it
>> point by default to ~/tmp/, a user-private tmpdir, instead.)
> Not sure where you get the "more secure" bit from.
> The temp directoy in /tmp is created with access rights for only the
> users themselves, not access for group or other. Directories in /home
> are often created with read access for group, which is not always a
> group specific to that user but something common like "users".
> Putting the KDE tmp directory outside /tmp also means that it won't be
> cleared automatically on reboot. /tmp is also often located on fast
> media, e.g. in a RAM disk, a solid state disk or a smaller but fast
> harddisk, etc.
I actually agree with all the usual reasons to put it in /tmp. And yes,
my /tmp is tmpfs mounted thus operating at memory speed and automatically
cleared at reboot.
However, there are certain security issues with having /tmp/ world-
writable (even sticky, as is traditional) in ordered for kde to create its
subdir in /tmp in the first place; in particular, certain issues relating
to predictable file/directory names, thus mktmp and similar utilities that
per-session randomize elements of the name. One way around that is a
strict policy of users get write permissions only within $HOME, with
/tmp/ and /var/tmp/ reserved for root or at least system access only.
Another way around that would be having a boot-time (or for non-volatile /
tmp, one-time at setup) script initialize (as root) user subdirs in /tmp,
setting up per-user permissions accordingly, and only allowing users to
write to their pre-created subdirs, with /tmp itself thus having
permissions much like /home normally does, world readable but only root
writable, and each user having unique user-only readable/writable subdirs.
Meanwhile, yes, user home dirs are often created with group read access,
but the more secure distributions of which I speak normally have a home-
group per user policy, with a user's default groupname and username (and
often number as well) identical and unique to that user. They also tend
to have a default umask of 0077 instead of the less secure but more common
0027, so a user must deliberately set both a non-default group and change
the file permissions, in ordered to allow access beyond that specific
user. (And such files may have to be moved or copied out of home to a per-
user but group or world readable subdir of a system-wide sharing directory
as well, as a user's homedir may well be user-only readable, so even if a
file within it is make group or world readable or even writable, it
couldn't be accessed by anyone but the user, without moving it to the
users more generally readable subdir under the system sharing location.)
And any boot-time cleaning of /tmp, with a slight tweak of the script, can
be set to clean users tmpdirs instead or as well, if desired. Certainly
this is easily enough done at the distribution level. Similarly, bind-
mounts or the like can be used to put all those user tmpdirs on a common
tmpfs or similar fast media, tho in that case it'd be generally less
trouble to use the boot-time setup per-user /tmp/ subdirs.
FWIW, back years ago (2002-ish), I ran mandrake (I run gentoo now), which
at the time had a hardening script called Bastille Linux (now Bastille
Unix, apparently referencing both the French prison and the root meaning
of the term, "stronghold" or "fortress", wikipedia tells me). I'm not
sure what it does now, but IIRC back then it had three basic security
levels, low, high, and intermediate, with a bunch of questions whose
answers then modified the default security at the intermediate level.
Making /tmp/ root-only-writable and setting up per-user ~/tmp/ was one of
the steps that it took at the highest security level and optionally at the
intermediate level. Similarly, default umask, etc, was set based on
security level. As that was my Linux introductory period and my intro to
practical bash consisted of taking apart and rewriting mandrake's
initscripts, particularly the core one (sysinitrc maybe? it's been awhile
and the fast-boot improvements since then likely mean things are quite
different today) that set system time, etc, I learned a *LOT* about Linux
bootscripts and security, among other things, during that period.
That was, however, before SELinux was reasonably normalized, with pre-
written policies available for many things. These days, I imagine SELinux
is used to nail down security on the security-strict distributions,
enhancing even further the measures described above. (Obviously from the
context, I don't run such a tightly secure installation here, as I'm the
sole human user and thus I don't really need to, and I've not kept up on
modern high security practices.)
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master." Richard Stallman
More information about the kde-linux