tmp or tmp or tmpfs protection mostly not set as default setting

Discussion in 'all things UNIX' started by jna99, Mar 6, 2013.

Thread Status:
Not open for further replies.
  1. jna99

    jna99 Registered Member

    Apr 18, 2012
    Location:, Netherlands
    (title has a typo .. typed in "tmp or" twice, my apologies)

    Maybe the title of this post is not entirely clear, but I couldn't decide on a good title for this post.

    I enjoy my linux experience thus far. I find my system a bit more responsive, but that is subject to alot of things of course, maybe even a state of mind.

    Anyway, why is the tmp when located on a seperated partition not automatically set in /etc/fstab with nodev,nosuid,noexec and a chmod to 1777 or 3777 ?
    I've been searching on google about various basic security measures that are helpful in my opinion, but this particular tmp protection is not implemented in all distro's or the option is not in the initial installation options when manually configuring a partition setup.

    In case of /tmp and/or /var/tmp being on the same partition as where root is located you can create a loop device and mount it with nodev,nosuid,noexec.

    Anyway, I was just thinking if this helps preventing from programs being executed in a tmp location, why is this not enabled by default in all distro's ?
    I mean I don't mind looking for helpful security measures I can take myself, but just to be a bit safer right from the start would be nice I think.

    I forgot to mention /dev/shm but I realise that ubuntu has changed to /run I believe, so this may not be a universal security fix for all kinds of linuxes, except maybe for the /etc/fstab added parameters.

    Anyway, am I just being overconcerned or should the tmp environment be more hardened by default when installing a linux ?
    I was just wondering or maybe I'm just a bit thick and overlooking some issues I didn't think about.

    Maybe someone with more experience with security and linux can give a thought about this ?

  2. Mrkvonic

    Mrkvonic Linux Systems Expert

    May 9, 2005
    Hardened against who and what?
  3. Most current Linux distros already mount e.g. /run nodev,nosuid.

    Anyway this does not really matter; from what I've seen the kernel disallows end users setting root ownership on a file, and (apparently) from creating possibly dangerous device nodes. (Try recreating /dev/kmem as a limited user; you'll get a permission denied error.)
  4. NGRhodes

    NGRhodes Registered Member

    Jun 23, 2003
    I know one example is that most package managers use tmp and they quite often need to run scripts which could not be then run.

    Of course a work around for apt that is to remount exec when needed (a quick google shows can be done via apt.conf pre and post commands).

    Cheers, Nick
  5. I've always thought that aspect of Debian package management (using /tmp by default) was not very smart. nodev,nosuid probably doesn't matter much these days, but /tmp and /var/tmp probably should be mounted noexec because they are world-writable. I don't see any reason that the package manager should execute scripts from a world-writable directory (sticky bit or no).
  6. shuverisan

    shuverisan Registered Member

    Dec 23, 2011
    What do you guys actually observe as a consequence of mounting /tmp as noexec? I asked this on Ubuntuforums recently and the thread got buried.

    I've set up several Precise and Quantal installs this way, including my personal computers and the only thing that even hints something is not normal the install manager or terminal saying 'Can't cache run scripts.' This flies by quickly in the verbose output and you'd miss it easily. Everything completes and runs perfectly fine.

    Anyone experience differently?
  7. Yes. Last I time I tried it - on Sidux IIRC - lots of packages failed to install properly, and my system broke. Might have had something to do with basically running Sid, but I wouldn't take the risk; and it's better anyway IMO to give install scripts their own directory to run in.
Similar Threads
  1. amarildojr
Thread Status:
Not open for further replies.