[kde-linux] Splash screen import errors

[Duncan]

Kevin Krammer posted on Sat, 30 Jan 2010 12:14:25 +0100 as excerpted:

> On Saturday, 2010-01-30, Duncan wrote:
> 
>> $KDETMP
>> 
>> Allows to specify another path than /tmp where KDE stores its temporary
>> files.
>> 
>> (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