Securing /var and /tmp folders

VirtualTorus · 2018-09-02 20:45:11

Hi everyone,

To narrow things down, I'm setting up a SSH server that will also be accessible by a few friends. Overall, they will be able to access a local FTP server (download only) and have access to some hardware resources (GPUs for some machine learning ). Not to suggest they aren't trustworthy, but I find this to be a good excuse to exercise and learn good security practices.

I read through the security wiki section and I'm not really grasping the File systems section. Should one separate the /tmp and /var partitions from /? What are the benefits and setbacks of doing so? For my purposes, is it necessary?

eschwartz · 2018-09-02 21:01:46

Putting the directories on different mounted partitions will not help you harden the directory permissions.

It will however let you use fast RAM for temporary files that will get deleted as old and useless, every time you reboot.
Also, /var being a different filesystem is one way to set max usage quotas so a rogue logging process cannot accidentally write 400GB of logfiles and make you run out of space.

loqs · 2018-09-02 23:00:40

/tmp is separate by default [1] [2]

1 https://www.freedesktop.org/wiki/Softwa … leSystems/
2 /usr/lib/systemd/system/tmp.mount

VirtualTorus · 2018-09-02 23:46:38

@Eschwartz Thank you for clarifying.

@loqs That's interesting, I didn't know that! (I guess I didn't pay enough attention when using the 'df' command)

Trilby · 2018-09-03 00:00:26

Non-root users will not have write access to /var by default (with the exception of a few user-specific subdirectories in which case it is perfectly reasonable for them to have write access).

Just don't give these users root access (or sudo obviously) and standard *nix filesystem permissions will cover you very well against almost any foolishness. Deliberate maliciousness might be another story, but if that was the concern, these guests would certainly not have ssh access.

A much more realistic/practical concern would be how you are granting them ssh access and whether some other party (attacker) could ssh in by the same means. Really the only good answer to this is to use key login only (i.e. no password logins at all).

Last edited by Trilby (2018-09-03 00:02:34)

seth · 2018-09-03 06:17:58

Notice that if /home/virtualtorus/totallynotporn is eg. 755, they'll still be able to see your … pictures of kittens.
You might want to put them into a chroot jail?

VirtualTorus · 2018-09-03 22:00:35

@Trilby Makes sense.

@seth I could be wrong, but when one creates a new user in Arch, does it not default to having the new user's home directory with permissions 700? I don't think any of the home directory's contents could be explored or listed anyway even if permissions of subdirectories or files were readable by other users (with the exception of root).

seth · 2018-09-04 06:36:00

I was more wondering about your actual security concerns and whether you wanted to isolate them completely.
Also, ftr., it doesn't matter which permissions $HOME has, if $HOME/Documents is 755, the world can enter it.

eschwartz · 2018-09-04 06:43:20

seth wrote:

Also, ftr., it doesn't matter which permissions $HOME has, if $HOME/Documents is 755, the world can enter it.

Not sure what you mean here.

$ ls -ld $HOME $HOME/Documents
drwx------ 1 eschwartz eschwartz 1856 Sep  3 19:29 /home/eschwartz/
drwxr-xr-x 1 eschwartz eschwartz  116 Jun 21 17:59 /home/eschwartz/Documents/
$ sudo -u nobody ls /home/eschwartz/Documents
ls: cannot access '/home/eschwartz/Documents': Permission denied

seth · 2018-09-12 14:21:27

Sorry for the long delay.

This doesn't work because you're crossing a directory (/home/eschwartz/) which you lack permissions on - that doesn't mean you cannot enter the target directory (on which you've sufficient permissions)
The usual way to get there is to "exploit" some weakness (what is way too easy - i'll reveal that quite some time ago you could fool the system by changing the symlink under your ass) - what is not even a bug (ok: "depending on the definition", it's unwanted but your access is technically ok)
Try the most trivial

cd $HOME/Documents
sudo -u nobody bash
ls

(yes, you only exploited your own stupidity this way ;-)

Please do not rely on this. If you want to exclude others from a path, set permissions on that path. If you're not sure that you're too lazy, keep them away from your root directory.

VirtualTorus · 2018-09-14 03:35:35

seth wrote:

Sorry for the long delay.
This doesn't work because you're crossing a directory (/home/eschwartz/) which you lack permissions on - that doesn't mean you cannot enter the target directory (on which you've sufficient permissions)
The usual way to get there is to "exploit" some weakness (what is way too easy - i'll reveal that quite some time ago you could fool the system by changing the symlink under your ass) - what is not even a bug (ok: "depending on the definition", it's unwanted but your access is technically ok)
Try the most trivial
cd $HOME/Documents
sudo -u nobody bash
ls
(yes, you only exploited your own stupidity this way ;-)
Please do not rely on this. If you want to exclude others from a path, set permissions on that path. If you're not sure that you're too lazy, keep them away from your root directory.

Interesting, I learn something new everyday.

In terms of security, do you have a more elaborate example? I figure your code snippet is serving as more of a directory permissions example (in response to the above posts) than from a security standpoint, since the people I am allowing to use my server will not have permission to use 'sudo'.

eschwartz · 2018-09-14 04:28:19

seth, sure that would work. But that's a pretty specific case and deserves some specific mention. I've seen people try to share a previously unshared directory, by setting read/execute permissions on it... then getting surprised when their goal failed due to that same intervening directory.

"Also, ftr., it doesn't matter which permissions $HOME has, if $HOME/Documents is 755, then anyone in the world who can exploit some process to chdir(2) into $HOME $HOME/Documents (for example sudo can start you off in a directory you don't fundamentally have read access to) can further enter Documents/ do whatever they want because they've evaded your sole access restriction."

Last edited by eschwartz (2018-09-14 16:21:05)

brebs · 2018-09-14 08:37:56

seth wrote:

cd $HOME/Documents
sudo -u nobody bash
ls

In the above example, the shell was already granted access, as part of executing the cd command. All it shows is that sudo is awful. I use PAM to get root, nice & cleanly, instead:

$ cat /etc/pam.d/su-l 
#%PAM-1.0
auth		sufficient	pam_rootok.so
# Uncomment the following line to implicitly trust users in the "wheel" group.
auth		sufficient	pam_wheel.so trust use_uid
# Uncomment the following line to require a user to be in the "wheel" group.
auth		required	pam_wheel.so use_uid
auth		required	pam_unix.so
account		required	pam_unix.so
session		required	pam_unix.so

... and the convenient:

alias s='su -'

If you're going to imply that fundamental filesystem security models are broken, then please come up with a better example

eschwartz · 2018-09-14 12:19:18

I'm mind-boggled, how you can deduce that sudo without `-i` is broken and awful, by using sudo *with* `-` as your proof. That's pure and simple cheating.

brebs · 2018-09-14 12:29:00

I'm not using sudo, I'm using PAM.

$ sudo
bash: sudo: command not found

Last edited by brebs (2018-09-14 12:29:45)

eschwartz · 2018-09-14 13:45:42

I'll reiterate, you're being disingenuous.

brebs wrote:

In the above example, the shell was already granted access, as part of executing the cd command. All it shows is that sudo is awful. I use PAM to get root, nice & cleanly, instead:

But that's simply untrue, it shows no such thing. You may have completely separate and unrelated reasons for believing sudo to be awful, but those reasons have absolutely nothing to do with this thread, so please stop implying falsehoods.

brebs · 2018-09-14 14:45:48

Eschwartz wrote:

... can exploit some process to chdir(2) into $HOME (for example sudo can start you off in a directory you don't fundamentally have read access to) can further enter Documents/ because they've evaded your sole access restriction."

My point there is that sudo runs as *root* (and therefore has access), and isn't checking whether user "nobody" should have access, and is therefore behaving awfully (i.e. confusingly/surprisingly) by disregarding the normal security model.

eschwartz · 2018-09-14 15:14:01

brebs wrote:

Eschwartz wrote:
... can exploit some process to chdir(2) into $HOME (for example sudo can start you off in a directory you don't fundamentally have read access to) can further enter Documents/ because they've evaded your sole access restriction."
My point there is that sudo runs as *root* (and therefore has access), and isn't checking whether user "nobody" should have access, and is therefore behaving awfully (i.e. confusingly/surprisingly) by disregarding the normal security model.

And my point is that *so does su*. It too has remained chdir'ed into that directory, without checking whether user "nobody" should have access (or testuser in this case, because the "nobody" user does not really exist and thus has no login credentials to authenticate with):

$ ls -ld $HOME $HOME/Documents
drwx------ 1 eschwartz eschwartz 1922 Sep 14 09:55 /home/eschwartz/
drwxr-xr-x 1 eschwartz eschwartz  116 Jun 21 17:59 /home/eschwartz/Documents/
$ su testuser
Password: 
$ pwd
/home/eschwartz/Documents
$ ls
archlinux-2018.09.01-x86_64.iso  archlinux-2018.09.01-x86_64.iso.sig
$ ls $PWD
ls: cannot access '/home/eschwartz/Documents': Permission denied
$ logout
$ su - testuser
Password: 
$ pwd
/home/testuser
$ logout
$ sudo -iu testuser
[sudo] password for eschwartz: 
$ pwd
/home/testuser

So much for your "sudo is a security hole".

...

Now, it's entirely possible that your insane, reactionist, instinctive, blind, completely uninformed hatred of the word "sudo" results in you being so cluelessly uninformed that you're not even aware that sudo -u username does in fact log you in as the other user, not as root -- just like su does, except that sudo checks your suders credential to determine via *your* login password via policy rules, whether you are allowed to do "it", whereas su checks if you know the *other* user's login password.

But there's absolutely no excuse for your having failed to notice my previous post where I asserted the same thing that you said "runs as root", does not in fact work *due to permission denied errors* (for root, according to you!) and both me and seth highlighted this point by using the "-u nobody" flag to sudo. So in order to remain ignorant, you'd need to not be reading our posts either.

Well, I guess I do believe you're not reading anything we say. Bye.

Last edited by eschwartz (2018-09-14 15:17:36)

ewaller · 2018-09-14 15:34:27

>be_nice_to_each_other
no.
>sudo be_nice_to_each_other.
okay.

Last edited by ewaller (2018-09-14 15:34:51)

Trilby · 2018-09-14 15:41:15

sudo -u nobody is_nice_to_each_other > the_internet

eschwartz · 2018-09-14 15:54:54

Added to which:

brebs wrote:

All it shows is that sudo is awful. I use PAM to get root, nice & cleanly, instead:
$ cat /etc/pam.d/su-l 
#%PAM-1.0
auth		sufficient	pam_rootok.so
# Uncomment the following line to implicitly trust users in the "wheel" group.
auth		sufficient	pam_wheel.so trust use_uid
# Uncomment the following line to require a user to be in the "wheel" group.
auth		required	pam_wheel.so use_uid
auth		required	pam_unix.so
account		required	pam_unix.so
session		required	pam_unix.so
... and the convenient:
alias s='su -'
If you're going to imply that fundamental filesystem security models are broken, then please come up with a better example

You allow absolutely anyone logged in as you to su to absolutely anyone they please with no validation whatsoever. You do realize this is exactly why Windows was always the least secure OS?

Never mind "fundamental filesystem security models", you have engineered your own breakage of the fundamental Unix permission models. People have learned to recognize and be afraid of sudoers

%wheel ALL=(ALL) NOPASSWD: ALL

, but when you do the exact same thing to su, via incredibly ill-advised PAM rules, that's going to escape immediate notice...

But no, sudo is evil and should be shunned, while your pam.d rules for su, are soooooooooooo superior that you need to interject in random threads about how sudo is evil.

Last edited by eschwartz (2018-09-14 15:56:07)

brebs · 2018-09-14 16:08:19

And my point is that *so does su*. It too has remained chdir'ed into that directory

True, good point.

However, I'm still waiting, to see an example of:

"Also, ftr., it doesn't matter which permissions $HOME has, if $HOME/Documents is 755, then anyone in the world who can exploit some process to chdir(2) into $HOME (for example sudo can start you off in a directory you don't fundamentally have read access to) can further enter Documents/ because they've evaded your sole access restriction."

I cannot replicate that security hole (going into a subdir) which you quoted. E.g.:

[root@brebsc ~]# useradd testuser
[brebs@brebsc ~]$ install -d -m 777 worldprivs

# Just checking
[brebs@brebsc ~]$ ls -ld /home/brebs/worldprivs
drwxrwxrwx 2 brebs users 4096 Sep 14 16:44 /home/brebs/worldprivs


# Test using su
[brebs@brebsc ~]$ su testuser
[testuser@brebsc brebs]$ pwd
/home/brebs
[testuser@brebsc brebs]$ cd worldprivs
bash: cd: worldprivs: Permission denied

# Test using sudo
[brebs@brebsc ~]$ sudo -u testuser bash
[sudo] password for brebs: 
[testuser@brebsc brebs]$ pwd
/home/brebs
[testuser@brebsc brebs]$ cd worldprivs
bash: cd: worldprivs: Permission denied

Both fail, as expected, so please explain "can further enter Documents/".

Edit: To clarify: /home/brebs is chmod 700.

You allow absolutely anyone logged in as you...

The protection is that they have to be *logged in*

Last edited by brebs (2018-09-14 16:11:06)

Trilby · 2018-09-14 17:45:41

brebs wrote:

The protection is that they have to be *logged in*

I have no dog in this fight overall, but this point doesn't really help you. Any random script that gets run under your user will essentially have root access. This is, effectively, no different than running everything as root. Hell, even a webpage you visit could get access to anything it wanted.

This statement is like saying your computer is only vulnerable when it is turned on. That may be true, but it is - I'd assume - frequently turned on. I'd also assume, you're frequently logged in. Saying you're only vulnerable while logged in is a bit silly.

Last edited by Trilby (2018-09-14 17:46:42)

brebs · 2018-09-14 18:28:49

Trilby wrote:

Any random script that gets run under your user will essentially have root access.

Hmm, yeah, let me check how to prevent that

$ cat testsu.sh 
#!/bin/bash

su -l -c "ls /root"

Edit: I suppose the only solution is to go back to requiring a password, by commenting out the "auth sufficient pam_wheel.so trust use_uid" line in /etc/pam.d/su-l.

Anyway, my primary interest in this thread is the "evaded your sole access restriction" comment, and whether there's a real security weakness involved.

Last edited by brebs (2018-09-15 11:28:56)

Arch Linux

#1 2018-09-02 20:45:11

Securing /var and /tmp folders

#2 2018-09-02 21:01:46

Re: Securing /var and /tmp folders

#3 2018-09-02 23:00:40

Re: Securing /var and /tmp folders

#4 2018-09-02 23:46:38

Re: Securing /var and /tmp folders

#5 2018-09-03 00:00:26

Re: Securing /var and /tmp folders

#6 2018-09-03 06:17:58

Re: Securing /var and /tmp folders

#7 2018-09-03 22:00:35

Re: Securing /var and /tmp folders

#8 2018-09-04 06:36:00

Re: Securing /var and /tmp folders

#9 2018-09-04 06:43:20

Re: Securing /var and /tmp folders

#10 2018-09-12 14:21:27

Re: Securing /var and /tmp folders

#11 2018-09-14 03:35:35

Re: Securing /var and /tmp folders

#12 2018-09-14 04:28:19

Re: Securing /var and /tmp folders

#13 2018-09-14 08:37:56

Re: Securing /var and /tmp folders

#14 2018-09-14 12:19:18

Re: Securing /var and /tmp folders

#15 2018-09-14 12:29:00

Re: Securing /var and /tmp folders

#16 2018-09-14 13:45:42

Re: Securing /var and /tmp folders

#17 2018-09-14 14:45:48

Re: Securing /var and /tmp folders

#18 2018-09-14 15:14:01

Re: Securing /var and /tmp folders

#19 2018-09-14 15:34:27

Re: Securing /var and /tmp folders

#20 2018-09-14 15:41:15

Re: Securing /var and /tmp folders

#21 2018-09-14 15:54:54

Re: Securing /var and /tmp folders

#22 2018-09-14 16:08:19

Re: Securing /var and /tmp folders

#23 2018-09-14 17:45:41

Re: Securing /var and /tmp folders

#24 2018-09-14 18:28:49

Re: Securing /var and /tmp folders

Board footer