# Filesystem securing

## LIsLinuxIsSogood

Hey I just took a look at my / folder on one of my boxes and noticed the following permissions:

```

jonathanr@playboy / $ getfacl tmp

# file: tmp

# owner: root

# group: root

# flags: --t

user::rwx

group::rwx

other::rwx
```

Output of mount command has the following in it:

```
/dev/shm on /tmp type tmpfs (rw,nosuid,nodev,noexec,relatime)

```

So from security standpoint, which of these seems to matter most, obviously the bottom one is just a good idea, but have I "undone" all the goodness about it by modifying the permissions to the file system in that way.  I would assume this is the result of a basic chmod but is there some way to double check or maybe that is the way tmp looks always (I forgot)...help![/code]

----------

## NeddySeagoon

LIsLinuxIsSogood,

```
drwxrwxrwt  10 root root    220 Jun 16 12:52 tmp
```

Put the 't' back. Without it everyone has full access to everything in /tmp.

----------

## LIsLinuxIsSogood

Ok it was already there.  That means I shouldn't worry ?

----------

## NeddySeagoon

LIsLinuxIsSogood,

That means /tmp is set up following normal good practice.

----------

## Hu

The configuration looks fine to me.  By ancient tradition, /tmp is user/group/world read/write/search, with the sticky bit (t) to inhibit the worst abuses that world write would otherwise permit.  (However, there are numerous common mistakes that can still be made by applications working in a world=rwx directory, which is why any application that cares about security at all should start with a mkdtemp and do all its work in the private secured subdirectory.)  Mounting nosuid,nodev,noexec is good practice.  In theory, nosuid is irrelevant if noexec is set, since the setuid bit cannot matter if the program cannot run at all.  Likewise, nodev should be irrelevant since only root should be allowed to create device nodes, and you trust root not to do that inappropriately.  Setting noexec is very valuable.  It prevents anyone from executing programs on that filesystem, even when permissions would otherwise allow it.

I like to set noexec on every filesystem where doing so does not break approved programs.  Generally, you want to minimize the number of locations where an untrusted user has both write permission and execute permission.  As a first level goal, you want not to have any well-known paths (like /tmp) that are write+execute for untrusted users.  As a second and more difficult goal, you want not to have any paths at all that are write+execute for untrusted users.  If you can achieve one of those goals, you can make it substantially more trouble for an intruder to leverage certain types of vulnerabilities into full and arbitrary code execution on the system./ - must not be noexec.  You will almost certainly break your running system if you set this noexec.  You can recover by rebooting (assuming you did not configure your system to set this again on boot).  Technically, the problem is not / itself, but /bin, /sbin, and /lib - all of which are normally on /, so it is usually easier just to tell people not to make / noexec./usr (if separate) - must not be noexec./tmp - should be noexec./var - should be noexec/var/tmp - should be noexec, except:/var/tmp/portage - must be exec for some packages, which expect to execute configure scripts or, even worse, locally built helper programs, during the build./home - this is controversial.  Setting it noexec can help, but it will inconvenience users and it will make developers hate you./dev/shm - should be noexec.

----------

## khayyam

 *Hu wrote:*   

> [...] (However, there are numerous common mistakes that can still be made by applications working in a world=rwx directory, which is why any application that cares about security at all should start with a mkdtemp and do all its work in the private secured subdirectory.)

 

Hu ... I'd add to this that these same applications should support/respect TMPDIR, many don't (particularly with the advent of XDG fluffery).

best ... khay

----------

## LIsLinuxIsSogood

Thanks for the responses. My comments below are to Hu's suggestions, which seems to address this new partitioning scheme for /var and /home I'm using as well.  I posted this right before undergoing some pretty serious partition changes to my hard drive and now have several things that I would like to get some opinions on.  Moving those parition does bring up the point about some of these options, like /var vs. /var/tmp (not sure about this one, since would that necessarily be a separate partition on disk, or some other fake device node like /dev/shm)? Anyway here are some new issues I am having with this machine, and this is NOT a production server environment or anything like that, so I am not concerned with pissing off any of the other users BESIDES myself. After moving /home to a new paritition I am having the following problems with applications:

1) Terminal emulator - something funny going on with the shell itself, but I need to dig further into this

2) GUI - panel applet crashing...really not sure why of all things this one part keeps happening...maybe reinstalling the mate-panel will help (or else it could be conflicting with the window manager I use)

As for these two issues, my plan was also to find out if the action of using chown -R (a recursive chown and chgrp on /home/user) would be safe since I just checked in there and looks like a lot of weird file ownership and group stuff.  But I don't want to do something that would be counterproductive, so I will backup it all up first before trying in case I need to restore the permissions/ownership as it was before.  In general though I would like to find out if the files in /home/user/././ are all meant to be owned by the user or can this vary with some of the hidden or configuration files in these locations according to application development standards. On a separate but related note Firefox web browser is crashing now because of something I did which is to remove files from /var/tmp/portage.  For some reason I thought I could remove these with no consequences, but it looks like this is now the reason for Firefox crashing as it looks for some gpm (Gecko) script of some kind.  I assume what is needed is just to reinstall, but oddly enough when I tried reinstalling Firefox-bin and that is also crashing for what appears to be another reason.

some further comments

 *Quote:*   

> /usr (if separate) - must not be noexec.
> 
> 

 

It is not and don't really understand then why this would ever be advised since / is already there to house this type of thing...

 *Quote:*   

> /tmp - should be noexec.
> 
> 

 

Ok, this makes sense and I want to be sure that I get it right....so do I change this in /etc/fstab how?   I am mounting something as a tmpfs, are there other options besides noexec to include?  What about the dump/pass variables what should those be set to for this location and does it not matter here due to the type of mount being /dev/sdhm

 *Quote:*   

> /var - should be noexec
> 
> 

 

Ok this is actually interesting because I would not have thought to do that.  But since I also just separated /var into its own partition at the same time when I was moving /home so now I will try to make a point to include noexec option here.  

 *Quote:*   

> /var/tmp - should be noexec, except:
> 
> 

 

Confused about this one.

 *Quote:*   

> /var/tmp/portage - must be exec for some packages, which expect to execute configure scripts or, even worse, locally built helper programs, during the build.
> 
> /home - this is controversial. Setting it noexec can help, but it will inconvenience users and it will make developers hate you.

 

Very confused about this one

 *Quote:*   

> /dev/shm - should be noexec.

 

Duh

----------

## Hu

 *LIsLinuxIsSogood wrote:*   

> Moving those parition does bring up the point about some of these options, like /var vs. /var/tmp (not sure about this one, since would that necessarily be a separate partition on disk, or some other fake device node like /dev/shm)?

 I mount a tmpfs on /var/tmp.  I seem to recall that this is technically a violation of some standard that says /var/tmp must be persistent storage.  I've never had any problems I can trace back to my non-compliance on this point. *LIsLinuxIsSogood wrote:*   

> 2) GUI - panel applet crashing...really not sure why of all things this one part keeps happening...maybe reinstalling the mate-panel will help (or else it could be conflicting with the window manager I use)

 On principle, I would say this is a bug.  It should not crash, no matter how badly you broke any of its data files or what other programs send it. *LIsLinuxIsSogood wrote:*   

> As for these two issues, my plan was also to find out if the action of using chown -R (a recursive chown and chgrp on /home/user) would be safe since I just checked in there and looks like a lot of weird file ownership and group stuff.

 Probably, but without understanding why the current ownership exists, it is hard to say definitively that the proposed changes to ownership would be necessarily better. *LIsLinuxIsSogood wrote:*   

> In general though I would like to find out if the files in /home/user/././ are all meant to be owned by the user or can this vary with some of the hidden or configuration files in these locations according to application development standards.

 Usually, they would all be owned by the user.  However, it's not unreasonable that there might be special applications that behave differently.  We would need a summary of files with "unexpected" ownership to judge if any are supposed to be that way.  You could use find ! -user username to create such a list. *LIsLinuxIsSogood wrote:*   

> On a separate but related note Firefox web browser is crashing now because of something I did which is to remove files from /var/tmp/portage.  For some reason I thought I could remove these with no consequences, but it looks like this is now the reason for Firefox crashing as it looks for some gpm (Gecko) script of some kind.  I assume what is needed is just to reinstall, but oddly enough when I tried reinstalling Firefox-bin and that is also crashing for what appears to be another reason.

 I suspect your diagnosis is incorrect.  Removing the files under /var/tmp/portage should have been safe.  Please provide the raw data that led to your diagnosis. *LIsLinuxIsSogood wrote:*   

> some further comments *Quote:*   /usr (if separate) - must not be noexec. It is not and don't really understand then why this would ever be advised since / is already there to house this type of thing...

 It should not be advised.  I put that line there because, while some speculative uses of noexec could turn out harmless, it's very likely that speculatively marking /usr as noexec would cause considerable short-term harm. *LIsLinuxIsSogood wrote:*   

>  *Quote:*   /tmp - should be noexec. 
> 
> Ok, this makes sense and I want to be sure that I get it right....so do I change this in /etc/fstab how?   I am mounting something as a tmpfs, are there other options besides noexec to include?  What about the dump/pass variables what should those be set to for this location and does it not matter here due to the type of mount being /dev/sdhm

 You need to distinguish between tmpfs (the filesystem type) and /tmp (a location commonly implemented using a tmpfs).  Some tmpfs, such as the one for Portage compilation, must be exec (but can be secured with permissions to prevent arbitrary users from using it to run unauthorized programs).  Others, such as the ones used for /tmp and /dev/shm can be noexec.  Yes, you should change this in fstab, since the tmpfs is mounted fresh on every boot.  Yes, you should include nodev for thoroughness.  Hopefully, you will never have a device node there and so it will never matter.  In practice, nodev is practically free security for those mounts where it makes sense, so you may as well include it solely because it is free.  Dump/pass can be 0.  They do not make sense here. *LIsLinuxIsSogood wrote:*   

>  *Quote:*   /var/tmp - should be noexec, except: Confused about this one.

 What is confusing?  /var/tmp, like /tmp is often a globally writable area.  That makes it an ideal target for abuse, therefore an ideal target for noexec.  The only catch is that $PORTAGE_TMPDIR (traditionally /var/tmp/portage) needs to be mounted exec.  If $PORTAGE_TMPDIR is merely a directory on the filesystem that owns /var/tmp, then the obvious way of making /var/tmp be noexec will also make /var/tmp/portage be noexec, which you do not want. *LIsLinuxIsSogood wrote:*   

>  *Quote:*   /var/tmp/portage - must be exec for some packages, which expect to execute configure scripts or, even worse, locally built helper programs, during the build.
> 
> /home - this is controversial. Setting it noexec can help, but it will inconvenience users and it will make developers hate you. 
> 
> Very confused about this one

 What do you want me to explain?  /home is writable by users and, if not mounted noexec, users can install and run their own native programs in their home directories.  If your goal is to minimize the ability to run unauthorized programs, you need to minimize places where they can be started.  That means making /home be noexec.  However, power users frequently have perfectly safe convenience tools that they found or wrote, that they store under /home.  Those tools will also be blocked (in some cases completely; in other cases, only made inconvenient to use) by mounting /home as noexec.  Unlike some of the other mount points, legitimate users (especially developers, but even some non-developer power users) can have good reasons for running code from /home.  The noexec mount option does not distinguish good reasons from bad reasons.  That is why it is controversial.

----------

## mv

 *Hu wrote:*   

> I mount a tmpfs on /var/tmp.

 

It depends on the programs you are using. For instance, portage's default is to store ccache there. Using ccache on a non-persistent storage is rather pointless.

----------

## LIsLinuxIsSogood

So the default for ccache is easily moved with a changed variable, but unless /var/tmp is supposed to be noexec then how does /var/tmp/portage become "accessible" to programs like firefox which I think I already mentioned is spitting errors about missing pipes to files I think relating to Gecko gmp-auto something. (Those files are supposed to be in /var/tmp/portage/ except that I deleted this to make space.)

If possible I would like to know how I might recover firefox without having to rebuild it, since that took over 4 hours I think not sure though.  I am thinking that in one of my backups it should be possible to dig up the bin/executable along with the necessary other files like libraries to install it without having to recompile.  Please advise

----------

## krinn

 *LIsLinuxIsSogood wrote:*   

> If possible I would like to know how I might recover firefox without having to rebuild it, since that took over 4 hours

 

If it take long time and you want shorter this when re-emerging, solve is pretty easy, you should enable (per package as you seems to care about space) binary package for that package.

The recovering would had been easy and should had taken like 5s.

Remember also any nfs directory can be use as binary holder (this to balance space eaten on that host).

If you don't have two hosts, and that host is lacking space, well, dunno, what is that shitty computer?  :Smile: 

----------

## LIsLinuxIsSogood

Thanks krinn, unfortunately I think I opened a can of worms now asking about that question.  I will just mark this situation as solved for now, because I think there is enough information between this here and the security handbook to read up on the proper way to secure the filesystem.

The one thing I am still confused about it would have to be /var/tmp/portage and its purpose

----------

## krinn

I'm agreeing with Hu there, firefox shouldn't crash because /var/tmp/portage is empty, so you're diagnosis is incorrect. You could verify (it's not really need as per logic, no dev would use something from /var/tmp/portage except for installing the package) this by checking files install per that package, either on your host with equery f pckname or thru https://packages.gentoo.org/

I suspect your firefox issue is more related to your /home folder with bork user/perms ; each /home directory should only hold files for each user, if you want share datas between your users, pickup a directory outside /home

/var/tmp/portage is a space holder for portage when installing package, no more.

----------

## LIsLinuxIsSogood

The main fact I have there is a terminal shell output that suggests at the same time of crashing it could not locate a piped file in the /var/tmp/portage directory.

So while that isn't anything too definitive, but it is rather specific.

----------

## LIsLinuxIsSogood

https://packages.gentoo.org/useflags/gmp-autoupdate

This was the use flag enabled for firefox that gave me the idea that it was therefore related

----------

## LIsLinuxIsSogood

I believe that clearly USE=buildpkg for at least this appication would have saved a ton of time, but @krinn I don't think the solution for me is going to inolve an NFS share since that might be more ideal if all systems ran the same package/version, but on the two boxes I have (one is a laptop and one is a desktop) that have Gentoo installed not only are they running different profiles (1 multilib and 1 no-multilib) but also the experimental flag is only enabled on one machine, so there is a good chance that trying to centralize the binaries in just one folder (nfs method), but I guess given the possibility for subfolders within the root nfs share that is one possible solution.  Or else as I suppose may also make sense given the variety of packages is to keep these binaries in a few different locations on the machine with more disk space (obviously the desktop) and that might mean accessing it through SSH.  I do like the idea of NFS for this, but it doesn't feel like the use case is going to warrant another export (which will hardly ever get use).  But it seems like just a preference thing anyway. Thanks for the suggestion!

----------

## krinn

 *LIsLinuxIsSogood wrote:*   

> I don't think the solution for me is going to inolve an NFS share since that might be more ideal if all systems ran the same package/version

 

I didn't speak about a binary server, an nfs directory on desktop could be use to store binary package of the laptop, even if it's the laptop that create them ; so using desktop space to gave space to laptop.

----------

## LIsLinuxIsSogood

I see, so the nfs share would serve the purpose of moving the binary packages back and forth from laptop to desktop, either after building on the laptop, or after messing up the laptop system and needing to retrieve it from NFS share on remote disk (desktop)

----------

## krinn

 *LIsLinuxIsSogood wrote:*   

> I see, so the nfs share would serve the purpose of moving the binary packages back and forth from laptop to desktop, either after building on the laptop, or after messing up the laptop system and needing to retrieve it from NFS share on remote disk (desktop)

 

Not moving them, just creating them on the share.

It's not limit to portage, you can create any nfs "i_need_space" on desktop, export that, and laptop could create directories you wish in it, and bind anything from laptop to them (but remember nfs speed has to be taken, as it will create slowness to bind /var/tmp to it per example). But you have plenty usage where the laptop doesn't need to hold itself the files while will still be able to use them easy (/usr/share/doc...) or could live without them (if desktop is down).

----------

## Hu

 *mv wrote:*   

>  *Hu wrote:*   I mount a tmpfs on /var/tmp. 
> 
> It depends on the programs you are using. For instance, portage's default is to store ccache there. Using ccache on a non-persistent storage is rather pointless.

 That depends on how often one reboots versus how often one rebuilds programs that benefit from ccache.  :Wink:   Even assuming timely reboots for every minor kernel patch, ccache can be useful on smaller programs (i.e. not web browsers) when experimenting with local patches to select source files.  Your larger point is a good one though - ccache is certainly hindered by the implicit clearing that use of a tmpfs would cause, and by the reduced capacity available. *LIsLinuxIsSogood wrote:*   

> So the default for ccache is easily moved with a changed variable, but unless /var/tmp is supposed to be noexec then how does /var/tmp/portage become "accessible" to programs like firefox which I think I already mentioned is spitting errors about missing pipes to files I think relating to Gecko gmp-auto something. (Those files are supposed to be in /var/tmp/portage/ except that I deleted this to make space.)

 As I said above, $PORTAGE_TMPDIR must be exec or far too many packages break.  This does not mean all of /var/tmp must be exec though; only /var/tmp/portage (assuming you do not relocate $PORTAGE_TMPDIR). *LIsLinuxIsSogood wrote:*   

> If possible I would like to know how I might recover firefox without having to rebuild it, since that took over 4 hours I think not sure though.  Please advise

 As I said above, please provide the raw data you used to determine that Firefox was broken.  Right now, all we have is your general statement that it is broken and some paraphrased hints of error messages.

You did mention gmp-autoupdate.  Based on its vague description, I disabled this on my system because it sounded like it was related to the HTML5 DRM plugin mess.  In particular, the USE flag description suggests it will be downloading native code to my home directory, then trying to load it into the browser.  I anticipated that would fail badly with noexec home.

----------

## NeddySeagoon

LIsLinuxIsSogood,

nfs is just a way to attach some remote disk space to your local filesystem tree.

nfs is not secure. If you need it on an untrusted network, you will need to tunnel it over ssh or something like that.

Then you have the crypto overhead both ends.

You can put the portage tree and distfiles there and share them as they are common to all arches.

You can have a packages directory per different configuration too and only mount them where it makes sense,

Its only as fast as your network though.

Don't put things there that you must have, so you can take the laptop away and still use it.

----------

## mv

 *NeddySeagoon wrote:*   

> nfs is not secure.

 

For the simple purpose of just remote mounting the portage tree, distfiles, and perhaps to share bin-packages, it is much safer and simpler to use net-fs/sshfs.

----------

## LIsLinuxIsSogood

 *Quote:*   

> Firefox was broken. Right now, all we have is your general statement that it is broken and some paraphrased hints of error messages. 

 

Firefox was broken but no longer and i did not have to reinstall or compile any code maybe it was related to my shell rc file which i noticed went missing luckily having a bzckup of that cleared up some issues related to my user.

 *Quote:*   

> nfs is not secure. If you need it on an untrusted network, you will need to tunnel it over ssh or something like that. 

 

Regards to nfs versus ssh in a private home network maybe this is different than a public or even work/office setting since my guess would be that nfs is really meant for the standard uses that ssh could do at  more of a pro level.  Since i have nfs exports already to both disks (for operating system and backup) then i think it makes sense to break apart the question about one versus the other for the separate uses or shares on my network.  SSH seems like the bad ass option of all remote sharing but there is something to be said about the ease of working with a simple file like exports in nfs.

Maybe my goal will be to therefore utilize both, the ssh method (more fine grained control) and the nfs method (ease or accessibility).

As for the security issue with nfs, on  private network what harm does it really do anyway?  Assuming the shares are all done read only then what should my concerns be about, is it an intruder (granted access) or malware (executing program code)?

kiLast edited by LIsLinuxIsSogood on Mon Jun 18, 2018 9:55 pm; edited 1 time in total

----------

## LIsLinuxIsSogood

 *Quote:*   

> For the simple purpose of just remote mounting the portage tree, distfiles, and perhaps to share bin-packages, it is much safer and simpler to use net-fs/sshfs.

 

Have not tried this but i think i will.  Since like mv says one of the primary goals here could be to mainatin integrity of the operating system files in that way.

----------

## LIsLinuxIsSogood

Well I can attest that going the nfs route whether secure or not has issues of its own in terms of permissions, and also ownership I am getting a ton of errors krinn, not to blame you since I am sure that someone else invented it.

Actually I have had many positive (and negative) experiences with NFS, but I think it is certainly time to give sshfs a try!

----------

