New answers tagged

0

Use an appropriate directory to store your web documents, so that you do not need to disable SELinux. These directories are: /var/www /srv/www And if you have problems, don't grope around blindly; check the logs to find out the specific problem.


-1

Even though I disabled SELinux by modifying the config file it was still enabled. I had to run the command 'setenforce Permissive' and it worked!!


0

Place the root administration machine into the room locked with two keys, and give only one for each of the two admins. The admins will always work together, observing each other activities. It should be the only machine containing the private key to login as root. Some activities may need no root rights, so only part of the work would require to go to ...


0

It appears that ROOT_SQUASH hadn't yet propagated out. I ran the following command a bit later and saw ROOT_SQUASH in the results: mmnfs export list --nfsdefs /comp/zixf401/NFS I then logged out of the Linux VM I was testing the NFS mount on and logged back in. After running the sudo su command and then attempting to chmod 770 one of the folders in the ...


0

Well, technically, if you do not enforce stronger security, then NFS by default will use auth_sys, where client simply tells NFS server which UID and GID to use, IOW no security. The best way to solve this issue is to export with sec=krb5 and enforce RPCSEC_GSS. You already have AD, which is kerberos server with LDAP. Check this link to see how to configure ...


1

Thank you @ThoriumBR: sudo chmod a+rx /crenfs Solved this problem


0

I'm thinking this question might not be possible to answer fully without some more details, such as: How many sysadmins do you expect to keep "restricted"? What do people need "sysadmin" access to do? First of all, be aware of what you can do with sudo. With sudo, you can permit elevated permissions to run only a single command (or variations, like ...


2

There are so many ways to simulate something going down. You've already said one which is to use iptables block rules. Another really simple way - unplug the network router so that your monitoring software can still see the host, but the host can't talk to S3 (or anything else for that matter). To me, this is the simplest but may in some cases not be ...


1

I cannot block write access if the bucket is meant to be read from and written to by the root user, and is monitored by the root user. This story starts and ends with the fact that this bucket needs to be accessed via IAM. Your root account on AWS exists only to setup the IAM roles. Once you've got that setup, you can alter the IAM privileges to test.


3

This is your baseline discussion: http://security.stackexchange.com/questions/7801/keeping-secrets-from-root-on-linux You split your responsibility by having security engineers whose job it is to make system configurations and installs, but they get no credentials or access to machines in production. They also run your audit infrastructure. You have ...


1

Why not just check for the existence of a specific file in the S3 bucket. If it's not there, throw your SNMP trap. Creating/deleting this file will make it very simple to verify that your script is working properly.


0

Doing proactive checking is very difficult. Solutions like http://software.dell.com/solutions/privileged-management/ (I do not work for Dell and other similar solution are available) are very effective in enforcing sysadmin accountability.


1

Another way how to lower risk (use next to those mentioned before, not instead of) is to pay good money to your sysadmins. Pay them so good that they don't want to steal from your IP and leave you.


8

What you are talking about is known as the "Evil Sysadmin" risk. The long and short of it is: A sysadmin is someone who has elevated privileges Technically adept, to a level that would make them a good 'hacker'. Interacting with systems in anomalous scenarios. The combination of these things makes it essentially impossible to stop malicious action. Even ...


1

The only practical way is restricting who can do what with sudo. You could potentially also do most of what you want with selinux but it would probably take forever to figure out the correct configuration which may make it impractical. Non-disclosure agreements. Hire a sysadmin, they have to sign an NDA, if they break their promise, take them to court. ...


8

It would be similar to the challenge of hiring a janitor for a building. The janitor gets to have all the keys, can open any door, but the reason is that the janitor needs them to do the job. Same with system admins. Symmetrically one can think of this age old problem and look at ways trust is granted historically. Although there's no clean-cut technical ...


18

Without putting yourself into an insane technical mind twist to try and come up with a way to give a sysadmin power without giving them power(its likely doable, but would ultimately be flawed in some way). From a business practice standpoint there is a set of simple solutions. Not cheap solution's, but simple. You mentioned that the pieces of IP you are ...


46

Everything said so far here is good stuff but there is one 'easy' non technical way that helps negates a rogue sys admin - the four eyes principle which basically requires that two sysadmins be present for any elevated access. EDIT: The two biggest items that I've seen in comments are discussing cost and the possibility of collusion. One of the biggest ...


1

Admins by the nature of the job have access to everything. They can see every file in the file system with their admin credentials. So, you'll need a way to encrypt the files so that admins can't see it, but the files are still usable by the teams that should see it. Look into Vormetric Transparent Encryption ...


26

If people truly need admin access to a system then there is little you can do to restrict their activities on that box. What the majority of organisations do is trust, but verify - you might give people access to parts of the system but you use named admin accounts (e.g. you don't give them direct access to root) and then audit their activities to a log ...


9

It is very very hard to secure hosts against those with administrative access. While tools like PowerBroker attempt to do this, the cost is adding both something else that can break AND adding barriers to attempts at fixing it. Your system availability WILL drop when you implement something like this so set that expectation early as the cost of protecting ...



Top 50 recent answers are included