Having read a bit recently about security when mounting devices, I was perusing /proc/mounts on my OpenSuse 12.3 system (as you do) and I noticed the following:
/home and /var lack the usual nosuid, noexec and other similar ‘security’ options. I tried adding them, and when I rebooted it all went horribly wrong.
So I logged in as root and reverted to the above. But I’m curious - the default settings look insecure. What should I do to make them secure (making /boot read-only sounds a good start).
In general, protection should come from proper ownership and access bits. And of course by using root properly (no login as you hint you are doing, strong passwprd, etc.). Most often people will not even have separate file systems for /boot and /var and thus doing what you try is normaly not even possible. Nevertheless these systems are not considered to be extra vulnerable.
Extra precautions should however be taken when mounting less trusted file systems, like those coming from other systems. Specialy when they are non-Linux file systems (read: Windows types).
When you have a separate /boot, making it read-only will prevent in any case any changes there, including new kernels that come to you through the Update repo as a security update.
/home and /var lack the usual nosuid, noexec and other similar ‘security’ options.
I do not know why you use the word “usual” here. IMHO it is very unusual to use those on these. E.g. the noexec on /home will prevent all users from using executables, being it binaries or scripts, stored within their home directories. I also see no use in blocking users from making use of the SUID feature. It is their responsability. After all it is not about SUID root. While there could be cases where you want to restrict your users, but this is not “usual”.
Firstly, “/boot”. Yes, you can make that ro (read-only). But then you will run into problems when doing updates. Some updates install a new kernel. Other updates regenerate the “initrd” file, or regenerate the grub menu.
If you want to make that ro, then manually remount it as rw before running updates.
For “/var”. I suspect “noexec” would cause problems, though I haven’t checked closely. I would guess that “nosuid” would be okay.
For “/home”. Many people put personal executables or executable scripts in their $HOME/bin, so “noexec” would cause headaches. For most folk, “nosuid” would be okay.
These are not usually security issues, because both “/home” and “/var” are normally part of your installed system and files only get their ownership and permissions via the standard means. So if you were to create a file on “/home”, you could not make it root owned without first becoming root. And you could not make it “suid” if owned by other than you, without first becoming root. And if you know the root password, you are assumed to be trustworthy.
The problem comes when plugging in a USB. Somebody could have created a root-owned suid program on that USB. They could have created it on a different computer, where they do have the root password. And that would give them root access to your system, where they do not have the root password. So a USB is normally mounted “noexec” and “nosuid” to avoid that risk.
The usual idea, then, is to have restrictions on file systems that are not a normal part of your installed system, but to trust the file systems that are part of your normal installed system. I hope that makes sense.
It makes a lot of sense, and clears up something that I was confused by. I was taking my lead from a section on making the system more secure in a book I have “Linux Complete”. but now I understand a little better.
Only recently I plugged an USB stick of my daughter, which before that she used on some windows PC at her school.
There was some ‘autorun.inf’ (or so) designed to be run under windows without asking the user before.
But that script was malicious and would have started the execution of a worm.
So when plugging that USB stick without checks whether any code on it should be run without asking,
that at least on any windows system would have been harmful.
On 2013-10-27 02:56, nrickert wrote:
>
> ratzi;2593808 Wrote:
>> Only recently I plugged an USB stick of my daughter, which before that
>> she used on some windows PC at her school.
>> There was some ‘autorun.inf’ (or so) designed to be run under windows
>> without asking the user before.
>
> Yes, that was a terrible design decision for Windows.
You have the choice of disabling autorun.
It was designed to make life easier for dumb users, but it backfired
when malware learned to use that door.
Truth is, security makes life harder.
–
Cheers / Saludos,
Carlos E. R.
(from 12.3 x86_64 “Dartmouth” at Telcontar)
I do notice that there are many world-writable files on my system. Most are owned by root:root and are in /var/tmp, or beneath /dev, but many are in /home/<username>, owned by <username>:users.
Are these a security risk? I only have two user accounts, for me and my wife, and no need for anyone else to access anything in another user’s home directory.
I normaly wouldn’t create world writable files as a user. I do not know why you and your wife have them. End-users are of course responsable themselves for this. But as long as nobody else can login it is not realy dangerous.
By setting your umask you can influence the access that is granted on file creation. E.g. with an umask of 027, the creation of a file will then have no access bits for world and no write access bit for group. You can of course still change that on the existing file when you want. Check what your umask is at the moment with
umask
BTW
In /dev there are some world writable, but those are devices where normal users should be able to write to (like /dev/null). You can be pretty sure that that iis secure enough. And /ddev is not easy to temper with because it is regenerated at every boot.
In /var/tmp I only have three directories owned by three different users, none of them accessable by group or world.
When you need to grant access (read and/or write) to your wife on a file, the do it on the group lvel. Of course you and your wife should then be members of the same group. But you probably are both members of the default group: users. Whenever you create a new account for somebody else you must then think of creating another group and put her/him in there.
> I do notice that there are many world-writable files on my system. Most
> are owned by root:root and are in /var/tmp, or beneath /dev, but many
> are in /home/<username>, owned by <username>:users.
Care to give examples?
> Are these a security risk? I only have two user accounts, for me and my
> wife, and no need for anyone else to access anything in another user’s
> home directory.
To answer precisely, please post some examples (file and permissions as
given by "ls -l filename).
–
Cheers / Saludos,
Carlos E. R.
(from 12.3 x86_64 “Dartmouth” at Telcontar)
umask = 0022. I’m not sure what that means (4 digits?). I guess it means 022, with an extra leading zero for SUID or something?
This is the default that came with OpenSuse 12.3. It will give a default setting of 755 for all files, will it not? Why does OpenSuse use this default, and give r-x access to world in home directories? It seems an odd setting. However although most files have rwxr-xr-x, there are still some with rwxrwxrwx. How, I don’t know. One of life’s mysteries. I’ll change them to rwxr-x— (750) and change the umask to 022 as you suggest, and see if that sorts it out.
But as you rightly say, if only two people can login in (and only I know the root password anyway) it’s probably secure enough. I was anxious of the risk of an outsider (over my internet connection) installing a rootkit or something else gaining access as root, but then that person would have root access and nothing would be secure!
Adding to the first remark:
The umask is a mask that will swittch off certain bits. It will not switch on bits. The application/tool that asks the kernel to create a file will offer access bits with that request. The kernel will take those and then switch off bits that are on in the request and are on in the umask. Thus if a program request rw------- (600) for a file to be created and the umask is 027, it will be created 600.
And for the default value. It is you the system manger that should know about installation defaults and eventualy change them to system wide defaults when needed. The user then can again change to a umask (s)he likes as the personal default to be set at login. I admit that not many people do know about this, but that does not remove their respnsabolity IMHO ;).
One of the first things I allways do for more then 40 years now is, after getting a new account: change the umask in my .profile (and more of those).
> It’s not the files themselves I am concerned about, it the fact that
> such files can be created that concerned me.
Anybody can create files with whatever permissions they choose, as long
as they have permissions to do so when they do. It is even possible to
create files which later you (the owner) can not even read or change.
You can not impede that.
–
Cheers / Saludos,
Carlos E. R.
(from 12.3 x86_64 “Dartmouth” at Telcontar)
That’s fine for a business system, but for the ‘general public’? I suggest that if Linux is to move into the mainstream (don’t we all want that?) it will need to be much friendlier in this respect. I would guess that if Windows hadn’t been so ‘un-lockeddown’ until relatively recently and thus much harder (albeit it safer) to use, it wouldn’t be so widespread because the general public would have been continually frustrated by it, and walked away. I’m not arguing that it is good to be insecure, but the security should be easier to control, IMHO.
Well, given that the users are me and my wife, and she wouldn’t have a clue about changing file permissions and I certainly haven’t explicitly set these permissions myself, the question remains - what is creating these files in this way? I guess I need to dig them out again. The names may give me a clue about the app that is creating them. I didn’t know until now that the creating app requests the file permissions. I thought it was the OS creating them from some default setting.
> Well, given that the users are me and my wife, and she wouldn’t have a
> clue about changing file permissions and I certainly haven’t explicitly
> set these permissions myself, the question remains - what is creating
> these files in this way? I guess I need to dig them out again. The names
> may give me a clue about the app that is creating them. I didn’t know
> until now that the creating app requests the file permissions. I thought
> it was the OS creating them from some default setting.
Well, again, if you want an answer, tell me the exact file and
permissions, as seen by “ls -l”. Then I might guess. Or not.
–
Cheers / Saludos,
Carlos E. R.
(from 12.3 x86_64 “Dartmouth” at Telcontar)
On 2013-10-31 08:16, haughtonomous wrote:
>
> hcvv;2594257 Wrote:
>> … It is you the system manger that should know about installation
>> defaults and eventualy change them to system wide defaults when needed.
>> The user then can again change to a umask (s)he likes as the personal
>> default to be set at login. I admit that not many people do know about
>> this, but that does not remove their respnsabolity IMHO
>
> That’s fine for a business system, but for the ‘general public’? I
> suggest that if Linux is to move into the mainstream (don’t we all want
> that?) it will need to be much friendlier in this respect. I would guess
> that if Windows hadn’t been so ‘un-lockeddown’ until relatively recently
> and thus much harder (albeit it safer) to use, it wouldn’t be so
> widespread because the general public would have been continually
> frustrated by it, and walked away. I’m not arguing that it is good to be
> insecure, but the security -should- be easier to control, IMHO.
No, I do not think so.
–
Cheers / Saludos,
Carlos E. R.
(from 12.3 x86_64 “Dartmouth” at Telcontar)
As Carlos says, as long as you have no facts, all is pure suggestion. So no comment from me until you show at least one of those files with wrong/dangerous permissions.
