Hot answers tagged

100

I'm going to disagree with the answers that say the age of the Unix security model or the environment in which it was developed are at fault. I don't think that's the case because there are mechanisms in place to handle this. The root permissions system makes sense, but on desktop systems, it feels like it protects the wrong data. The superuser's ...


90

No, this is not correct. While one may argue about the relative difficulty of finding and exploiting 0day vulnerabilities on Linux when you have local access, the security architecture itself of a modern Linux system (with an MMU) is designed to isolate different users and prevent privilege escalation. A non-root user cannot gain root without proper ...


62

You pretty much hit the nail on the head when you said that you need physical access to the machine. If you have physical access, you don't need to go through the official steps to reset the root password, as you can flips bits on the hard drive directly, if you know what you're doing. I.e., you can boot up a recovery OS from a DVD or flash drive, and ...


56

Security administrators are responsible for your machine and what happens on your machine. This responsibility violates the basic security model for a single-user Unix machine because the admin (an absent party) is root on your machine, you are not. Unix isn't really set up for this model. Admins need to be able to install security controls on your machine ...


55

Because the UNIX-based security model is 50 years old. UNIX underlies most widespread OSs, and even the big exception Windows has been influenced by it more than is apparent. It stems from a time when computers were big, expensive, slow machines exclusively used by arcane specialists. At that time, users simply didn't have extensive personal data ...


31

This is a highly astute observation. Yes, malware running as your user can damage/destroy/modify data in your home directory. Yes, user separation on single user systems is less useful than on servers. However, there are still some things only the root user (or equivalent) can do: Install a rootkit in the kernel. Modify the bootloader to contain an early ...


28

How is this not a glaring security vulnerability? It is. Physical access to your system is the ultimate vulnerability. Is there a way to disable this 'feature' so that it cannot be changed from GRUB like this? Can you do this in all other Linux distros as well? Or is this a Redhat exclusive ability? Make yourself aware of what is happening here: ...


26

To rephrase the quote - Privilege escalation vulnerabilities have existed and will continue to be found or created. During the last week we have this little doozy in SystemD; what are we going to have next week, will it be patched in time, and how good is your patching regime? You should assume that it's feasible that an attacker who can run on a box can ...


25

The original design of Unix/Linux security was to protect a user from other users, and system files from users. Remember that 30-40 years ago, most Unix systems were multi-user setups with many people logging into the same machine at the same time. These systems cost tens of thousands of dollars, and it was extremely rare to have your own personal machine, ...


25

A few reasons off the top of my head: ARP poisoning or network flooding attacks on the network would generally require root access to a machine on the network. Being able to install unauthorised programs might open the company up to legal liability if those programs are themselves illegal (e.g. because they're pirated or not licensed for for-profit use or ...


14

Exploiting a privilege escalation vulnerability is already hard enough, doing so while being certain that you don't leave a trace is much much harder. An Android user trying to root their phone can keep trying one exploit after the other, without worrying or having to cover up their traces. A student repeatedly trying to abuse sudo or spreading fishy ...


12

This answer is not meant to contradict the existing answers, but rather supplement them because it's too long for a comment. Part of the reason is (as others have alluded to) that users can't be trusted not to do foolish/malicious things. But another part is whose responsibility is it to fix things when that happens? I'm a full-stack developer and part ...


10

I assume you are concerned about containerized applications running as root. root in container is a risk. It still interacts with the kernel as root. And if an application manages to break out of container, it has root privileges on host. Though, root in container has restricted capabilities compared to root on host. E.g. it does not have capability ...


10

Is there no way to prevent malicious code happening in $HOME? To answer this question, what some installations do is make use of the existing security framework by making a user specifically to run the program. Programs will have a configuration option to specify as what user they should be running. For example, my installation of PostgreSQL has the ...


8

To answer the second part of your question: There are sandbox mechanisms, but they are not enabled by default on most linux distributions. An very old and complicated one is selinux. A more recent and easier to use approach is apparmor. The most useful for personal usage (apparmor and similiar systems are mostly used to protect daemons) is firejail, which ...


6

Oh dear. Sorry, but you goofed. You made a technical mistake and a legal mistake. You may be in trouble. Act carefully. The legal mistake is that just because you can take control of a machine, doesn't mean you're allowed to. Only the proper authority is allowed to decide who has the root password. From my understanding of what you wrote, you are not the ...


6

The issues are that anyone on your system will be able to maliciously elevate themselves to root privileges. Doing either of these things is a very bad idea. To address your specific scenarios: Making root's home directory mode 0777 means that all users will be able to read, write, enter, and execute any files in that directory. Because many sensitive, ...


5

I think "straightforwardly" means "without human tricks and other social engineering". So the answer is - Yes, if the systems contain unpatched 0-day that leads to privileges escalation. It could be an application-level 0-day. For example, if there are executables owned by root with setuid permissions which could affect arbitrary files. Latest reference is ...


5

You can consider this recommendation as a road sign that warns you about icy road. It does not prohibit you from driving fast. It just warns you that many people who drove fast had accidents. If you are a world champion in ice racing, may be you will just smile and drive further with the same speed. But for the most people following recommendation and ...


4

can I enable root access just by using ssh keys and be safe This depends on how well you protect the private key belonging to the authorized public key. I see no problem that somebody might brute-force the server directly to get access as root. But somebody might hack your client system, steal the private key and then use it to get root access to the server....


4

If you gave the program root access, you can't prevent it from accessing your account. (By “root access”, I mean “the highest level of privileges”. It's possible to run programs as the user root without granting them the highest level of privileges, through security frameworks such as SELinux. However, to get actual protection, you'd have to run the package ...


4

AFAIK, there are 4 main reasons not to give administrator access to standard users on their desktops: protect the machine itself (not always very efficient) and the other machines on the network from possible attacks using that machine as a relay (already covered by other answers) protect the IT support team from admin level attacks that will require a lot ...


4

You're right that sudo only grants elevated privileges to the command you run with it. What the commenter is referring to is that running processes in a Linux desktop session can watch the keystrokes on that desktop session without you knowing. So if you open a terminal window on your desktop, type sudo <some command>, and enter your password at the ...


3

...su -c ... theuser asks for teuser's password which is strange,... There is nothing strange about this but this is exactly how su is supposed to work. It might be useful to make yourself more familiar with the concepts behind su and sudo and how they differ. In short: su allows user A to execute a command as user B provided that user A can also ...


3

The presumption that the wrong data is being protected is false. Protecting root activities does protect your vacation pictures from 2011. And mine, and your brothers', and everyone else's who uses the computer. Even if you implemented an OS with a scheme that protected the home account by requesting a password every time an app tried to access a file, and ...


3

Some of the methods in this project -- https://github.com/scottyab/rootbeer -- are advanced-enough for most needs. However, r2frida and many other reversing methods will likely find a way around even these advanced root-detection mechanisms. Ideally, you are looking for both anti-rooting and anti-hooking -- http://d3adend.org/blog/?p=589 Also, you are ...


3

Quick note: latest versions of android (or one coming soon?) now have jailbreak protection built-in, and you can specify that you don't want your app installed on any jail-broken devices. This is a bit outside of my immediate area of expertise, but I think I have a good answer for you anyway. Like anything else, it's all about the cost/benefit analysis, ...


3

It rather depends what you mean by "invisible". It's not really possible to change the behaviour of the system and leave no detectable trace. All you can do is make it harder to find those traces. At the extreme end of the scale you could compile a kernel module capable of hiding itself which has an interface back into userspace - although this is far from ...


3

The root user will have access to, at the very least, the database file that is stored on the computer. This means reguardless of how the service is configured they can copy and delete the data. If your databse is not encrypted by some means he will be able to modify the data too.


3

Depending on your application, you might not need "all" the CA certificates, but only the ones that you are able to trust. You can use the Mozilla CA Certificate Store at: https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/ Those are the CAs that are trusted in e.g. Firefox.


Only top voted, non community-wiki answers of a minimum length are eligible