345

Do I need to verify the user for every single page? Absolutely. Not only every page, but every request to a privileged resource, e.g POST request to update data, delete, view, etc, etc. It is not just about viewing the pages, it is about controlling who can do what on your system. It sounds like your entire authentication and permissions system is broken ...


109

There's a number of reasons: If it has happened to one person, it might have happened to more. These other people might not be as kind. Who knows, this person might change their mind. When they made the effort to contact you, and just gets a "meh" in return, they might be a bit annoyed and decide to punish you for it. Or maybe they just want to poke around ...


105

The point is to protect against your disk being accessed outside of the OS. Encryption is useful against attackers who have physical access to your computer. Without it, it would be trivial to read out the content of your home directory, for example by plugging in a live boot USB stick.


98

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 ...


94

However, after putting some thought into it I can't come up with a reason why shared executable code on an internal server shouldn't have 777 permissions. Because you're not only trusting every user - which might be reasonable on an internal server where "everybody" who has access should have that control - you're also trusting every process on that ...


80

There's an even easier way to bypass the "execute" permission: copy the program into a directory you own and set the "execute" bit. The "execute" permission isn't a security measure. Security is provided at a lower level, with the operating system restricting specific actions. This is done because, on many Unix-like systems (especially in the days of ...


58

We always hear... Do we? I don't. Installing some untrusted program as a normal user is a bad idea with Linux the same it is with Windows or Mac: this program has access to all your data and can delete these data, send these data to somebody else etc. Moreover it can make screenshots, control other applications running on the same X windows screen (even if ...


58

While it's impossible to read the minds of the people at play - I'd think that the independent programmer A) Doesn't want to be accused of impropriety - It's much harder to be accused of IP theft if you kick and scream to have your access revoked post-haste. B) Is aghast at the security posture of the company that controls the private repository and knows ...


58

You can disable USB storage on Linux by blacklisting the module. modprobe -r usb-storage echo blacklist usb-storage >> /etc/modprobe.d/10-usbstorage-blacklist.conf echo blacklist uas >> /etc/modprobe.d/10-usbstorage-blacklist.conf If your users have physical access to the machine, and knows the encryption keys, the game is up no matter what ...


57

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 ...


40

There are two main reasons why smartphones have fine-grained permissions while desktop computers don't. History. Mainframe operating systems have a tradition of giving permissions to the user rather than to the program, and this carried over into minicomputers/workstations/desktops; the desire to maintain compatibility with existing programs limits the ...


38

The quick answer is yes, as you gathered. But it doesn't need to be the huge job you're thinking of. (The whole security thing might be big, but this is only one part of it). You have far more serious issues than that. Why it matters ANYTHING you create will be hit with attempts to break it. Someone will be curious. Someone will do something you never ...


33

In short: yes, being on a low-privilege account helps protect you against malware, but does not make you immune. Like any security measure, no single thing is going to keep you 100% safe. TL;DR: Running on a low-privilege account (aka "principle of least privilege") should be part of a balanced breakfast which also includes good firewall configurations; ...


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 ...


30

The Linux permissions only work on your own system. If you take the disk and put it in another computer, or just boot another OS on the same computer that can read your Linux partition you will plainly see that the permissions do not prevent you from accessing the content of your home directory.


28

You need to check the user permission level for every request (GET, POST, PUT, DELETE). Browsing to a page, like in your case is a GET request. A user shouldn't be able to post a request without permission as well. Now whether you need to add the code on each page of your application depends on your application framework. For example, some frameworks (...


27

In computer security, they are used interchangeably. In the context of rights, permission implies consent given to any individual or group to perform an action. Privilege is a permission given to an individual or group. Privileges are used to distinguish between different granted permissions (including no permission.) A privilege is a permission to ...


27

You can set the execute bit, but not the read bit, on an executable file. That way, noone will be able to copy the file, but people can execute it anyway. This is quite pointless today, because a) it works for compiled programs only, not with scripts (on most systems); b) these days, with 90% of all unixes being linux, people can copy executables from just ...


26

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

I'm gonna second @gowenfawr and say that breeding better chimpanzees is a goal unto itself here. (now I will extrapolate wildly about your corporate culture) At my software development company, we've been seeing an increasing trend of customers asking for evidence of our security practices not just in production environments, but also in our development ...


22

If the system is private and you don't use any other infrastructure or services to carry out your testing, then you probably don't violate any statutes. However: If you are attacking through an ISP - get their agreement first, as they could see what you are doing as an attack and pass the info to law enforcement If there is data on the server which could ...


21

Client-server architecture This is another approach that could make copying files much harder, but it requires investing more effort from your side. Access to the information could be setup on a client-server architecture basis with information being stored in a database (such as MySQL or PostgreSQL) on a remote server in a secure location. Then, provide ...


20

For technical reasons it is not possible to tell which permissions an application needs until it tries to use them, which means that an application needs some way to declare this. Applications on desktop operating systems never did this. When the user starts a legacy application, you could only assume that it needs everything (training the user to accepting ...


20

In addition to blocking USB (see other answers above): Disable networking, because... ... otherwise user will use remote access to your machine, e.g. via scp or ftp, and copy files from your machine. ... otherwise logged in users will be able to transfer file via net from your machine to some other machine via scp, ftp, samba, http.


19

By default, only administrators can create symbolic links, because they are the only ones who have the SeCreateSymbolicLinkPrivilege privilege found under Computer Configuration\Windows Settings\Security Settings\Local Policies\User Rights Assignment\ granted. From Microsoft TechNet: Security Policy Settings New for Windows Vista: Symbolic links (...


19

One thing to note is that giving an additional user access to a repository opens up a whole new possible attack vector. If someone else with malicious intentions has access to the account which has been granted access to the repo without the original account holder being aware, that person could easily download your entire source code.


14

I would be reluctant to parcel out blame, particularly when it is clearly an honest mistake. Too much focus on blame on one incident can poison the well and make people more reluctant to report security incidents in the future. Even without any blame involved, it is already embarrassing enough to have to report that you screwed up and may have contributed ...


14

That the code "runs as root" is mostly irrelevant. Root or non-root is a distinction that makes sense only locally to a machine, and only if you want to contain some potentially hostile code (e.g. hijacked server code) without bringing down the whole machine. This is the mainframe model from a few decades ago. At that time, it was believed that you could ...


14

In addition to answers, there are a few minor caveats that one must keep in mind about these encrypted configurations. When you are not logged into your system, data in your home directory is not accessible in plain text. This, of course, is by design. This is what keeps an attacker from gaining access to your files. However, this means that: Your cronjobs ...


13

Get a known clean version of your site and identify the differences between the known good code the and current (hacked) production code. Study how the changes may have been made and repair. Update the passwords. Fix the FTP certificate issue - consider using 2 factor authentication. Find a way to scan your code for vulnerabilities - peer review or ...


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