When I conduct an interview, I often ask candidates to talk about a major mistake made by someone on their team in the past. I let them pretend it wasn't them, but someone else, but if they can't name a serious mistake made, they are either rather junior, or can't be trusted to tell the truth about an outage.
I run Slackware and BSD servers, and it is considered normal to edit their config files by hand, and it is certainly quicker and more efficient to do so.
Because you can't be expected to change by hand three config files on 5k systems in a reasonable amount of time.
I dare you to list 10 *Administrative* tasks that don't require root privileges.
1. User account validation (collecting proof that each ID on the system is still supposed to be there) 2. Reviewing security logs that are stored on a central server, accessible by the SA team's individual ID and no one else 3. Examining system availability data ("Is this system actually up and healthy?") 4. Validating network listeners, looking for undocumented ones 5. Checking performance statistics that you logged to a remote system 6. Doing a patch query to determine if any required OS patches are missing 7. Discussing a request for limited sudo rights with the application team, reviewing the script they want run as root 8. Writing the documentation for that upcoming change request, staging the necessary files into a test area. 9. Writing the script that will be run on every audited system to collect the data required by the external auditor. 10. Testing that firewall rule you just put in actually is set up right.
Ones I decided not to list, but I do all the time: * Work with the vendor so that their code doesn't need root to install or run * Work with the application users so that they don't write code that breaks security policy * Teach users how to properly submit that user access request * Provide feedback to management based on the results of some of the items above to request additional resources (people, hardware, software, miracles, etc.)
I didn't include writing cfengine policies, because that has to be done in my shop as a user that is not the default user. I could have easily set permissions to allow the SA team to write such as themselves, but chose not to. Hmm, I should think about doing that tomorrow. That'll add a huge category of "anything that can be done via configuration management" to the list.
Good luck complying with PCI DSS 8.2, 8.5.8 and 10.2.2. I've yet to see a single way to do so when using su. You must be able to produce a reliable off-host log of actions taken with administrative privilege, ensure that direct access to any account accessible by more than one individual is impossible, and that even knowing the password is insufficient to gain access to privileged accounts.
That's what I have to do to comply with PCI. I have similar requirements on other audits. As a result, root's password is locked away, any use is investigated and had better be accompanied by a problem ticket explaining how hosed the box was that su was the only way to repair it. Use of a logging shell (either individual sudo commands, or sudo to a logging shell) is mandatory here.
It isn't about getting in the way or not getting in the way. It's about keeping track of what happened on the system. Human actions are just another thing to keep track of. We expect the system to log significant events so that they can be examined later in case of a problem. The interactive commands run by humans with administrative access is even more important because it is unpredictable.
Change their shell to a logging shell. If you need one, grab ksh-93 source and turn on SHOPT_AUDIT. It's now part of RHEL as of I believe 5.4, so no code build needed there. Then you just start monitoring euid 0 and point the logs to the syslog port of your central log server.
ssh as root? You just got your wrist slapped for violation of security policy, direct login as root destroys individual accountability. The root password is only available when you break the glass container with the envelope because nothing else will repair the box. Every user, including the sysadmins, are required to use their individual accounts to log in, then elevate their privileges through a tool like sudo to obtain superuser access. Most of the time, the SA has written policies for cfengine or puppet or some similar tool to keep the system running without actually logging in.
So many times, people who think they are seasoned, forget that funny thing called security.
As for vi, I use it because I can count on it being there on any Unix based OS. I don't count on any feature that won't be on HP-UX, RHEL, Solaris, AIX, Digital Unix, or whatever other OS I have to use today. When I script, unless I personally put it out, I only use features I know are distributed on all Unix based operating systems I'll touch. That means I rarely even use perl, because I have a lot of legacy boxes that don't have any version of perl on them.
I agree with your criticisms of numbers seven and nine above.
The author feels like a case of one year experience, repeated fifteen times.
We used to use rootsh (very similar to sudosh), but killed it because of some nasty cases where users could go into vi, and enter escape sequences to do nasty things to the person reading the audit log in less or vi. We also realized that rootsh's lack of remote logging meant that a clever user could do something nasty then write an at job to clean up the logs (including of the atjob itself running or being scheduled) erasing all history of their nastiness. After catching one person who was doing things like that, we had little choice but to accept that on-host logging was never acceptable.
Anything that logs what is sent to your screen means your security log will eventually have sensitive information like cleartext passwords, maybe even a credit card number. Now your security log must be treated at all times as a potential repository of such information. Logging too much is just as bad as logging too little.
Users here have been well educated that they are not to change shells. Vendors have never required an install as full root that also required a non-standard shell. It's always a tradeoff. I like the ksh-93 solution partially because it is freely available, partially because it just works. Our logging requirement has been consistently the command line history, never full keystroke. It isn't intended to stop every admin. It's intended to provide protection against those cases where you must give temporary full root to an application contact. Putting such limitations there is much more reasonable.
You missed a few things that may not have been clear from my above comments.
We never give vi or similar commands via sudo for temporary or limited sudo. Explicit in our policy is that any command that permits a shell escape must not be given via sudo.
More important, for a more complete access (full shell), we use an auditing shell. This provides the SA team the access they need to do their job, but we can catch a significant amount of abuse, and still balance the needs of the business.
The security review team is a separate team. Not even they have the ability to edit the actual logs. That's a third team.
Here, powerbroker is banned precisely because it is a keystroke logger in default configuration. We implemented sudo + ksh-93 instead to ensure we wouldn't log keystrokes. We know that very often, users are typing passwords in, configuring conf files for applications, etc.
Your root password management I like. The devil is obviously in the details of how the password is changed and stored in the database, but such systems have proven to be a very good thing. My suggestion would be to implement a "break glass" mechanism into it. If the root password is requested by the system, it automatically schedules a password change for that system one day later.
At work, I worry about these and other issues on a very large scale.
The logging shell must be non-blocking. Will it capture everything? No. If it logs every keystroke, it fails. If it logs everything sent to your screen, it fails. The reason why is left as an exercise for the reader.
The audit requirements have been satisfied for our auditors with command line history logging done in a reliable manner (reliable as in the data once captured is not alterable by the user).
As for X11 only configs, I tell the vendor they can implement a command line or they can lose a sale at a very large company. Maybe I've been lucky. But so far, it's worked.
The key is that the end user must not be greatly inconvenienced by the logging so that they do not feel like there is a reason to go around it. That's why I like the ksh-93 with auditing approach. It's a comfortable and familiar shell, but it logs their command line history in real time off-host. (Built into ksh-93, but not enabled in a default build).
What I look for isn't necessarily what they did after they took actions to evade logging, but did an action occur that could reasonably allow them to bypass logging?
As a nice side effect, some practices that were bad before are no longer allowed. Don't edit that file in place, check out a copy from your repository into place. Minimize the work done as root.
So have one of your standard security checks looking for people who open a sudo session to an unlogged shell. If they need a full shell, force them to use a logging shell (ksh-93 with SHOPT_AUDIT enabled can be configured to send to your remote syslog system as one option).
Your security review team needs to be examining sudo logs regularly (daily if PCI). Look for people who abuse their access. Look for what people are doing. This goes doubly true for temporary or limited escalated privilege.
Reviews and assessments ongoing for the past three years (and rereviewing at least one product). It is very possible we missed a few products that could work well. Aimed scope is in the >10k Unix system range (with assorted several thousand Windows servers and appropriate numbers of other device types).
When I say some below, I mean at least one.
Some could not perform all basic tasks of user account management (e.g. creating a user's group if it doesn't exist). Some would fail (refuse to create an account) if they were not allowed to set static local passwords even though your shop doesn't permit or use local passwords. Some couldn't handle a framework where one system couldn't reach every system directly in your enterprise.
The biggest flaw was logging. Very few products would log through standard logging mechanisms (e.g. syslog on Unix) what they were actually doing - on the box they were operating on. The logging done was usually done only on a central system (problematic for PCI DSS 10.2.7, creation of system objects, and 10.2.2, actions taken with administrative privilege.) This if you get any logging at all.
Another major flaw sometimes observed was some of these products tried to insist on direct login to a shell account to operate. "You want to have an account that can be remotely logged into and can execute any command with full administrative privilege because you require a few commands that can be trivially leveraged for full access?"
Some of the commercial tools couldn't (and some could) handle account revalidation, where a manager had to attest that an account is in fact still required on a periodic basis. This has replaced inactivity tests as more effective in some audits.
A hierarchical framework was rarely well supported to handle a heavily segmented network where no single system could see all other systems in the enterprise. I was dismayed how few products were agent pull based instead of central system push based. (I'm convinced of the value of a pull mechanism for security and supportability).
The backend was also sometimes an issue. Using a standard database so custom queries can be constructed against not only who has an account where, but who validated that account, when, what permissions it has, etc. can be very useful in an audit.
A coworker of mine rolled out several years ago a robust, audit hardened user management framework for Unix systems that does very well in audits that Active Directory routinely fails. This sits on an estimated 20k-30k Unix based systems of multiple flavors.
AD does not have a built in framework for account validation (asking appropriate authorities, does this account still need to exist?). The role based concepts are relatively primitive. There is no capability to preserve the authorization record for granting access. All of those concepts have to be added on.
Actually deploying accounts, nothing beats actual local accounts. The trick is to have a robust agent that actually manages those accounts.
I've reviewed some of the various enterprise grade products, and none of them did as well as this self-built product.
Most products for user management simply have no mind to the audits, only pretty pictures. There is rarely even any logging of value.
AD is really nothing more than LDAP + Kerberos with a pretty GUI. It simply should never be considered adequate in and of itself for user management because it does not address several key requirements of the area.
I wish they had gone in the article into more depth about grammar changes, rather than just word forms. For example, sentence ordering, comma usage, and some various other grammar items would be more intriguing. I found the burnt/burned the most interesting comparison because it showed an example of two competing versions of a word.
Interesting idea, but as was stated in the article, there are definite limits to what this technique can study, and many are unconvinced of its value for more than highly limited problems.
People like the illusion of privacy. They like that it is a minor nuisance to bother them and that they have a space that they can make a little bit more their own than is typically considered proper in a more open environment. I know that many people where I work were uncomfortable with open floor plans for this very reason. In some extreme cases, people have effectively constructed cube walls for themselves with books and other items just to let them work better.
The lack of visual distractions of others moving can be significant to some.
Tell that to those who have the job of escorting the field engineer onto the computer room floor, preparing the backup media for removal to secure storage, inserting new blank media into the backup silos when they run low, etc. They are also the ones I call when the monitoring tools are borked because the LOM card is on the fritz and I need someone to physically touch the system or look at it.
I work from home and have done so for over ten years now. I've made it work successfully. I will very openly state that many of my coworkers cannot effectively work from home.
The reasons that work from home isn't always a good idea vary. Some people require the human face to face contact. Others require the firmer separation, the act of actually going to another building to put them in the work mindset. Some do not have a home situation amenable to working from home. Some are just in jobs that require too much interaction with the rest of the team or just cannot be done remotely. (People who's job requires physical access to specific hardware without waiting an hour for the person to get there.)
Even many of my coworkers who do work from home make excuses to go into the office periodically to meet with peers for lunch. This helps smooth over issues so that work is done more smoothly.
This is the same problem that cryptographers have had for many years, including World War II. If the allies revealed that the German and Japanese codes were broken, the Axis powers would change their codes. But they needed to act on the intelligence.
A variety of methods were devised to obscure the real source of the intelligence. If you read about the history of cryptography, especially on World War II, you'll see mention of some of this stuff.
In my job, I'm not a coder or developer. But I have to look at what developers shove my way. It isn't uncommon for me to point out a fundamental flaw in their thinking that invalidates some or all of their code. Being a developer isn't enough. You have to know the area that the code is operating in. If the code is to do crypto, you need someone who knows crypto. If the code does statistical analysis, get a statistician to review it. This may seem obvious, but I've seen time and time again that it isn't.
Developers need to stop pretending that they are in a position to intelligently analyze algorithmic design in a complex field.
You forgot the theater's refusal to ever set the volume to an appropriate level. Proper sound levels doesn't have a screen whisper so loud that I'm wincing because it is above my comfortable threshold for volume. I gave up on theaters years ago. I don't have a huge screen, but I have a more comfortable chair, I have a sound system that I can set to the right volume, and I can pause if someone needs to get up for any reason.
There are more important things to me than a screen that is so large I can't see completely.
And here a retired English teacher I know and a professional writing instructor both have said almost the same thing you did, quite openly. Shakespeare has lots of sexual innuendo and gratuitous violence. After all, what is the point of Rosencrantz and Guildenstern? To up the body count in Hamlet.
Slashdot Mirror
When I conduct an interview, I often ask candidates to talk about a major mistake made by someone on their team in the past. I let them pretend it wasn't them, but someone else, but if they can't name a serious mistake made, they are either rather junior, or can't be trusted to tell the truth about an outage.
Why?
I run Slackware and BSD servers, and it is considered normal to edit their config files by hand, and it is certainly quicker and more efficient to do so.
Because you can't be expected to change by hand three config files on 5k systems in a reasonable amount of time.
I dare you to list 10 *Administrative* tasks that don't require root privileges.
1. User account validation (collecting proof that each ID on the system is still supposed to be there)
2. Reviewing security logs that are stored on a central server, accessible by the SA team's individual ID and no one else
3. Examining system availability data ("Is this system actually up and healthy?")
4. Validating network listeners, looking for undocumented ones
5. Checking performance statistics that you logged to a remote system
6. Doing a patch query to determine if any required OS patches are missing
7. Discussing a request for limited sudo rights with the application team, reviewing the script they want run as root
8. Writing the documentation for that upcoming change request, staging the necessary files into a test area.
9. Writing the script that will be run on every audited system to collect the data required by the external auditor.
10. Testing that firewall rule you just put in actually is set up right.
Ones I decided not to list, but I do all the time:
* Work with the vendor so that their code doesn't need root to install or run
* Work with the application users so that they don't write code that breaks security policy
* Teach users how to properly submit that user access request
* Provide feedback to management based on the results of some of the items above to request additional resources (people, hardware, software, miracles, etc.)
I didn't include writing cfengine policies, because that has to be done in my shop as a user that is not the default user. I could have easily set permissions to allow the SA team to write such as themselves, but chose not to. Hmm, I should think about doing that tomorrow. That'll add a huge category of "anything that can be done via configuration management" to the list.
Good luck complying with PCI DSS 8.2, 8.5.8 and 10.2.2. I've yet to see a single way to do so when using su. You must be able to produce a reliable off-host log of actions taken with administrative privilege, ensure that direct access to any account accessible by more than one individual is impossible, and that even knowing the password is insufficient to gain access to privileged accounts.
That's what I have to do to comply with PCI. I have similar requirements on other audits. As a result, root's password is locked away, any use is investigated and had better be accompanied by a problem ticket explaining how hosed the box was that su was the only way to repair it. Use of a logging shell (either individual sudo commands, or sudo to a logging shell) is mandatory here.
It isn't about getting in the way or not getting in the way. It's about keeping track of what happened on the system. Human actions are just another thing to keep track of. We expect the system to log significant events so that they can be examined later in case of a problem. The interactive commands run by humans with administrative access is even more important because it is unpredictable.
Change their shell to a logging shell. If you need one, grab ksh-93 source and turn on SHOPT_AUDIT. It's now part of RHEL as of I believe 5.4, so no code build needed there. Then you just start monitoring euid 0 and point the logs to the syslog port of your central log server.
ssh as root? You just got your wrist slapped for violation of security policy, direct login as root destroys individual accountability. The root password is only available when you break the glass container with the envelope because nothing else will repair the box. Every user, including the sysadmins, are required to use their individual accounts to log in, then elevate their privileges through a tool like sudo to obtain superuser access. Most of the time, the SA has written policies for cfengine or puppet or some similar tool to keep the system running without actually logging in.
So many times, people who think they are seasoned, forget that funny thing called security.
As for vi, I use it because I can count on it being there on any Unix based OS. I don't count on any feature that won't be on HP-UX, RHEL, Solaris, AIX, Digital Unix, or whatever other OS I have to use today. When I script, unless I personally put it out, I only use features I know are distributed on all Unix based operating systems I'll touch. That means I rarely even use perl, because I have a lot of legacy boxes that don't have any version of perl on them.
I agree with your criticisms of numbers seven and nine above.
The author feels like a case of one year experience, repeated fifteen times.
Or AIX, or HP-UX, or RHEL.
Measured boot times on some decent sized boxes:
Solaris: 40-75min
AIX: 30-70min
RHEL:20-40min
HP-UX: We gave up at 3 hours and restored from ignite
We used to use rootsh (very similar to sudosh), but killed it because of some nasty cases where users could go into vi, and enter escape sequences to do nasty things to the person reading the audit log in less or vi. We also realized that rootsh's lack of remote logging meant that a clever user could do something nasty then write an at job to clean up the logs (including of the atjob itself running or being scheduled) erasing all history of their nastiness. After catching one person who was doing things like that, we had little choice but to accept that on-host logging was never acceptable.
Anything that logs what is sent to your screen means your security log will eventually have sensitive information like cleartext passwords, maybe even a credit card number. Now your security log must be treated at all times as a potential repository of such information. Logging too much is just as bad as logging too little.
Users here have been well educated that they are not to change shells. Vendors have never required an install as full root that also required a non-standard shell. It's always a tradeoff. I like the ksh-93 solution partially because it is freely available, partially because it just works. Our logging requirement has been consistently the command line history, never full keystroke. It isn't intended to stop every admin. It's intended to provide protection against those cases where you must give temporary full root to an application contact. Putting such limitations there is much more reasonable.
Since sudo isn't installed by default on Solaris, does that include that too? Neither is rsync, and for years, SSH.
"I don't trust you, you don't trust me, I don't trust me."
Slogan of a good security admin
You missed a few things that may not have been clear from my above comments.
We never give vi or similar commands via sudo for temporary or limited sudo. Explicit in our policy is that any command that permits a shell escape must not be given via sudo.
More important, for a more complete access (full shell), we use an auditing shell. This provides the SA team the access they need to do their job, but we can catch a significant amount of abuse, and still balance the needs of the business.
The security review team is a separate team. Not even they have the ability to edit the actual logs. That's a third team.
Here, powerbroker is banned precisely because it is a keystroke logger in default configuration. We implemented sudo + ksh-93 instead to ensure we wouldn't log keystrokes. We know that very often, users are typing passwords in, configuring conf files for applications, etc.
Your root password management I like. The devil is obviously in the details of how the password is changed and stored in the database, but such systems have proven to be a very good thing. My suggestion would be to implement a "break glass" mechanism into it. If the root password is requested by the system, it automatically schedules a password change for that system one day later.
At work, I worry about these and other issues on a very large scale.
The logging shell must be non-blocking. Will it capture everything? No. If it logs every keystroke, it fails. If it logs everything sent to your screen, it fails. The reason why is left as an exercise for the reader.
The audit requirements have been satisfied for our auditors with command line history logging done in a reliable manner (reliable as in the data once captured is not alterable by the user).
As for X11 only configs, I tell the vendor they can implement a command line or they can lose a sale at a very large company. Maybe I've been lucky. But so far, it's worked.
The key is that the end user must not be greatly inconvenienced by the logging so that they do not feel like there is a reason to go around it. That's why I like the ksh-93 with auditing approach. It's a comfortable and familiar shell, but it logs their command line history in real time off-host. (Built into ksh-93, but not enabled in a default build).
What I look for isn't necessarily what they did after they took actions to evade logging, but did an action occur that could reasonably allow them to bypass logging?
As a nice side effect, some practices that were bad before are no longer allowed. Don't edit that file in place, check out a copy from your repository into place. Minimize the work done as root.
That's exactly the kind of thing your security reviewer needs to look for. "Executed vi, log trail corrupted, discipline the user."
So have one of your standard security checks looking for people who open a sudo session to an unlogged shell. If they need a full shell, force them to use a logging shell (ksh-93 with SHOPT_AUDIT enabled can be configured to send to your remote syslog system as one option).
Your security review team needs to be examining sudo logs regularly (daily if PCI). Look for people who abuse their access. Look for what people are doing. This goes doubly true for temporary or limited escalated privilege.
Reviews and assessments ongoing for the past three years (and rereviewing at least one product). It is very possible we missed a few products that could work well. Aimed scope is in the >10k Unix system range (with assorted several thousand Windows servers and appropriate numbers of other device types).
When I say some below, I mean at least one.
Some could not perform all basic tasks of user account management (e.g. creating a user's group if it doesn't exist). Some would fail (refuse to create an account) if they were not allowed to set static local passwords even though your shop doesn't permit or use local passwords. Some couldn't handle a framework where one system couldn't reach every system directly in your enterprise.
The biggest flaw was logging. Very few products would log through standard logging mechanisms (e.g. syslog on Unix) what they were actually doing - on the box they were operating on. The logging done was usually done only on a central system (problematic for PCI DSS 10.2.7, creation of system objects, and 10.2.2, actions taken with administrative privilege.) This if you get any logging at all.
Another major flaw sometimes observed was some of these products tried to insist on direct login to a shell account to operate. "You want to have an account that can be remotely logged into and can execute any command with full administrative privilege because you require a few commands that can be trivially leveraged for full access?"
Some of the commercial tools couldn't (and some could) handle account revalidation, where a manager had to attest that an account is in fact still required on a periodic basis. This has replaced inactivity tests as more effective in some audits.
A hierarchical framework was rarely well supported to handle a heavily segmented network where no single system could see all other systems in the enterprise. I was dismayed how few products were agent pull based instead of central system push based. (I'm convinced of the value of a pull mechanism for security and supportability).
The backend was also sometimes an issue. Using a standard database so custom queries can be constructed against not only who has an account where, but who validated that account, when, what permissions it has, etc. can be very useful in an audit.
A coworker of mine rolled out several years ago a robust, audit hardened user management framework for Unix systems that does very well in audits that Active Directory routinely fails. This sits on an estimated 20k-30k Unix based systems of multiple flavors.
AD does not have a built in framework for account validation (asking appropriate authorities, does this account still need to exist?). The role based concepts are relatively primitive. There is no capability to preserve the authorization record for granting access. All of those concepts have to be added on.
Actually deploying accounts, nothing beats actual local accounts. The trick is to have a robust agent that actually manages those accounts.
I've reviewed some of the various enterprise grade products, and none of them did as well as this self-built product.
Most products for user management simply have no mind to the audits, only pretty pictures. There is rarely even any logging of value.
AD is really nothing more than LDAP + Kerberos with a pretty GUI. It simply should never be considered adequate in and of itself for user management because it does not address several key requirements of the area.
I wish they had gone in the article into more depth about grammar changes, rather than just word forms. For example, sentence ordering, comma usage, and some various other grammar items would be more intriguing. I found the burnt/burned the most interesting comparison because it showed an example of two competing versions of a word.
Interesting idea, but as was stated in the article, there are definite limits to what this technique can study, and many are unconvinced of its value for more than highly limited problems.
People like the illusion of privacy. They like that it is a minor nuisance to bother them and that they have a space that they can make a little bit more their own than is typically considered proper in a more open environment. I know that many people where I work were uncomfortable with open floor plans for this very reason. In some extreme cases, people have effectively constructed cube walls for themselves with books and other items just to let them work better.
The lack of visual distractions of others moving can be significant to some.
Tell that to those who have the job of escorting the field engineer onto the computer room floor, preparing the backup media for removal to secure storage, inserting new blank media into the backup silos when they run low, etc. They are also the ones I call when the monitoring tools are borked because the LOM card is on the fritz and I need someone to physically touch the system or look at it.
I work from home and have done so for over ten years now. I've made it work successfully. I will very openly state that many of my coworkers cannot effectively work from home.
The reasons that work from home isn't always a good idea vary. Some people require the human face to face contact. Others require the firmer separation, the act of actually going to another building to put them in the work mindset. Some do not have a home situation amenable to working from home. Some are just in jobs that require too much interaction with the rest of the team or just cannot be done remotely. (People who's job requires physical access to specific hardware without waiting an hour for the person to get there.)
Even many of my coworkers who do work from home make excuses to go into the office periodically to meet with peers for lunch. This helps smooth over issues so that work is done more smoothly.
This is the same problem that cryptographers have had for many years, including World War II. If the allies revealed that the German and Japanese codes were broken, the Axis powers would change their codes. But they needed to act on the intelligence.
A variety of methods were devised to obscure the real source of the intelligence. If you read about the history of cryptography, especially on World War II, you'll see mention of some of this stuff.
In my job, I'm not a coder or developer. But I have to look at what developers shove my way. It isn't uncommon for me to point out a fundamental flaw in their thinking that invalidates some or all of their code. Being a developer isn't enough. You have to know the area that the code is operating in. If the code is to do crypto, you need someone who knows crypto. If the code does statistical analysis, get a statistician to review it. This may seem obvious, but I've seen time and time again that it isn't.
Developers need to stop pretending that they are in a position to intelligently analyze algorithmic design in a complex field.
You forgot the theater's refusal to ever set the volume to an appropriate level. Proper sound levels doesn't have a screen whisper so loud that I'm wincing because it is above my comfortable threshold for volume. I gave up on theaters years ago. I don't have a huge screen, but I have a more comfortable chair, I have a sound system that I can set to the right volume, and I can pause if someone needs to get up for any reason.
There are more important things to me than a screen that is so large I can't see completely.
And here a retired English teacher I know and a professional writing instructor both have said almost the same thing you did, quite openly. Shakespeare has lots of sexual innuendo and gratuitous violence. After all, what is the point of Rosencrantz and Guildenstern? To up the body count in Hamlet.