Correct Way of Securing /tmp and /var/tmp in FreeBSD

K

kiksilog

I have just started studying FreeBSD to use it as a web server. I'm almost done setting up everything.

My question is which is the right way of securing /tmp and /var/tmp in FreeBSD?

Are these commands correct?

Code: 
rm -rf /tmp
mkdir /tmp
rm -rf /var/tmp
mkdir /var/tmp
mount -t tmpfs -o noexec,nosuid,nosymfollow /tmp
mount -t tmpfs -o noexec,nosuid,nosymfollow /var/tmp
chmod 1777 /tmp
chmod 1777 /var/tmp
echo "tmpfs   /tmp    tmpfs   noexec,nosuid,nosymfollow        0       0" >> /etc/fstab
echo "tmpfs   /var/tmp    tmpfs   noexec,nosuid,nosymfollow        0       0" >> /etc/fstab

The first one I tried were these commands (from CentOS)

Code: 
rm -rf /tmp
mkdir /tmp
mount -t tmpfs -o rw,noexec,nosuid tmpfs /tmp
chmod 1777 /tmp
echo "tmpfs   /tmp    tmpfs   rw,noexec,nosuid        0       0" >> /etc/fstab
rm -rf /var/tmp
ln -s /tmp /var/tmp

But what that did was a
Code: 
mktemp: mkdtemp failed on /tmp/locatex4zybqBRGf: Permission denied
error when executing /etc/periodic/weekly/310.locate.

I've searched using Google but this is just the information that I got:

Secure /tmp and /var/tmp directories and mount it with noexec, nosuid, nosymfollow.
Click to expand...

Thanks in advance. :)
 
noexec and nosuid will work on tmpfs, nosymfollow will not.

Code: 
tmpfs			/tmp		tmpfs	rw,nosuid,noexec,mode=01777	0	0
tmpfs			/var/tmp	tmpfs	rw,nosuid,noexec,mode=01777	0	0
 
You also forgot the mode in fstab. Both /tmp/ and /var/tmp need to be world-writable and have their sticky(7) bit set.

After a reboot tmpfs(5) doesn't 'remember' the chmod(1) so it must be explicitly set in /etc/fstab.
 
Follow-up question

Thanks for the replies.

Are the following commands now correct? (Also for those who are searching for the same solution)

Code: 
rm -rf /tmp
mkdir /tmp
rm -rf /var/tmp
mkdir /var/tmp
mount -t tmpfs -o rw,nosuid,noexec,mode=01777 tmpfs /tmp
mount -t tmpfs -o rw,nosuid,noexec,mode=01777 tmpfs /var/tmp
echo "tmpfs   /tmp    tmpfs   rw,nosuid,noexec,mode=01777        0       0" >> /etc/fstab
echo "tmpfs   /var/tmp    tmpfs   rw,nosuid,noexec,mode=01777        0       0" >> /etc/fstab
 
Hi, my fstab on webserver looks like below. Should I add mode=01777 after noexec? Also maybe it's a good idea to add nodev there? Should I change 2 2 to 0 0? Thank you in advance.

Code: 
# Device        Mountpoint      FStype  Options          Dump    Pass#
/dev/vtbd0p2    /               ufs     rw                               1       1
/dev/vtbd0p3    none        swap  sw                               0       0
/dev/vtbd0p4    /var          ufs     rw,nosuid,noexec        2       2
/dev/vtbd0p5    /tmp        ufs     rw,nosuid,noexec        2       2
/dev/vtbd0p6    /usr          ufs     rw                               2       2
 
proton1234 said:
Hi, my fstab on webserver looks like below. Should I add mode=01777 after noexec? Also maybe it's a good idea to add nodev there? Should I change 2 2 to 0 0? Thank you in advance.
Click to expand...
First of all please keep in mind that you're responding to a thread which is over 6 years old. Although some of the participants are still active today it's usually safer to start a new thread. Especially if your problem isn't exactly the same as the original question or presented problem.

Anyway, what are you trying to achieve? Better security? Now, I know I'm playing the devils advocate right now but seriously: how do you expect to keep your server safe if you apparently don't fully grasp the theory behind the things you're trying to do? Security isn't achieved by merely enabling a certain setting or installing a certain program. True security is gained by gaining an understanding in the way things work.

First things first: man fstab, this will open the fstab(5) manualpage which fully explains the way your filesystems are set up. It's even mentioned in the quote you shared: Dump and Pass. The first number is only used by the dump(8) program. So unless you actually use that to handle your backups and if you're actually interested in backing up your temporary data then I don't really see any added value in setting it.

But it's not something anyone can answer because it all depends on your backup scheme.

The second number is used by fsck when it's recovering a dirty filesystem. Once again the manualpage explains the details. Generally speaking it's best to use the value 1 for the root filesystem and higher numbers for the rest. There isn't a real 'good' or 'bad' here. I usually use 2 for system filesystems such as /var and /usr, then 3 for additionals (/usr/local) and higher for the rest.

Still, why rely on UFS instead of tmpfs as suggested by the OP? That might be easier on you.

As to your mode comment: don't bother. See also mount(8), that isn't a valid option when working with UFS. The permission bits are stored on the filesystem itself. So as soon as you mounted the filesystem then you'd set the permission ( # chmod 1777 /tmp) and those settings will then retain.

So for what's it worth I'd say your current settings should be suitable enough.
 
kiksilog said:
Code: 
rm -rf /tmp
mkdir /tmp
rm -rf /var/tmp
mkdir /var/tmp
Click to expand...

Well now I have to ask something. Why do we have to delete these folders, only to recreate them again? Can't we do whatever we want to do, with the already existing folders? Or are we looking at this from a security perspective, and thus ensuring we are clearing any 'historic changes' and starting fresh?
 
PacketMan said:
Or are we looking at this from a security perspective, and thus ensuring we are clearing any 'historic changes' and starting fresh?
Click to expand...
On a booted system there will be a couple of files in those directories. Removing it all to create a clean mountpoint is just good practice. I regularly do exactly the same. But, you're right, a rm -rf /tmp/* would have sufficed too.
 
Not really necessary if you use tmpfs(5). That's already completely empty after a reboot (it's a RAM disk). It is useful if you use a (disk) filesystem for /tmp/.
 
The leading zero doesn't change anything, I think it is only included to help the reader interpret it as an octal value. The 1 is significant however, and should be provided if you don't want different users to be able to remove (and by extension replace) other users' files. According to the tmpfs man page, the mode will rather sensibly default to the mode of the directory used as a mount point. So maybe just set those up correctly. I tend to use a memory-backed /tmp and a disk-backed /var/tmp, but the former set up as UFS over MD using mdmfs as the file system is more mature. In that case a mode (specified using -p) is necessary; also -t to enable TRIM and ensure memory gets released.
 
bds said:
The leading zero doesn't change anything, I think it is only included to help the reader interpret it as an octal value. The 1 is significant however, and should be provided if you don't want different users to be able to remove (and by extension replace) other users' files. According to the tmpfs man page, the mode will rather sensibly default to the mode of the directory used as a mount point. So maybe just set those up correctly. I tend to use a memory-backed /tmp and a disk-backed /var/tmp, but the former set up as UFS over MD using mdmfs as the file system is more mature. In that case a mode (specified using -p) is necessary; also -t to enable TRIM and ensure memory gets released.
Click to expand...
so on your opinion what will be the final variant of fstab partiton strings?
Code: 
/dev/vtbd0p4          /var     ufs     rw,nosuid,noexec,mode=01777      2      2
/dev/vtbd0p5         /tmp    ufs     rw,nosuid,noexec,mode=01777      2      2
 
Last edited by a moderator:
Don't set 1777 permissions on /var/!

And because these are "real" filesystems you don't have to add the mode at all. You can remove the rw too, it's the default.

You only need to set the mode on RAM disks (because those filesystems disappear when you reboot).

Don't set noexec on /var/tmp if you use mergemaster(8). It's going to break because it needs to execute scripts from there.
 
You must log in or register to reply here.
Back
Top