As a side note, if our hypothetical programmer merely examines and untaints $ENV{PATH} in the last example, the exploit will succeed, since Perl doesn't do any taint inspection of a string passed to system() unless it interpolates potentially tainted input. Still, a reasonable programmer would hopefully have an "ah ha" moment after being reminded that $ENV{PATH} is tainted and consider the rest of the environment.
I don't think you're being argumentative at all. Your points are fair and valid, and I'll note that the specific example provided (per the comments embedded in it) is a bit on the contrived side. That said, Perl actually used to just use whatever it found in $ENV{SHELL} for system() calls, which would have removed the necessity of including the explicit/bin/bash call to trigger the bad behavior, but that behavior was fixed some time ago. Other programming languages and environments may be quite a bit more lax, shifting more of the security burden onto the general operating system environment and further abstracting unsafe lower-level calls away from the programmer.
However, the earlier example is still quite useful for demonstrating another Perl best practice: taint mode. I have seen some truly dreadful things done via shell-outs in various languages, because programmers are of course capable of doing all sorts of very silly and dangerous things in their programs (such as including direct shell binary invocations in system calls), frequently without realizing those things are that dangerous in context. This may be due to the dangers being difficult to anticipate, and this could be said of our first example, as it doesn't contain any code that visibly uses external data. Here's what happens when we turn on taint mode in the initially exploitable script: Perl taint mode saves lives.
If I get the time, I'll be setting up various test environments with an assortment of examples written in different languages and frameworks to demonstrate the sorts of differences described herein, and I'll be glad to keep you posted if you like.
I'm perfectly capable of fixing things myself. That's not the issue here. Try enforcing the policy you described across even a moderately sized multi-tenant SMB computing environment running a variety of applications that you're responsible for managing. You'll soon find that your policy results in negative revenue. The end result becomes a case study in "you broke it, they stopped buying it."
The Zimbra example is only a single case intended to illustrate the mere existence of #!/bin/bash in scripts on commonly deployed systems; there are many, many others to be found, including wrappers for various commonly used utilities than may well wind up being called from a CGI script. As for your last sentence, you're conflating two concepts. I was specifically addressing the following response: "Certainly not in a distribution which does not have bash as the system shell. You can uninstall bash in such a distribution, and the system is expected to continue running." See the difference?
I'll add a note that a couple of network daemons I've recently authored are designed to be started under any given shell, including Bash, but they also communicate over raw TCP sockets instead of CGI, get exec-ed into a shell with an explicitly blank environment (blank as in "no environment vars are set whatsoever"), chroot themselves to a safe filesystem with noexec specified for the mount, drop privileges to "nobody" (again, with no env vars available and hence nothing for the shell to parse), mlock their process memory, and run under Perl's hard taint mode which requires regex whitelist examination of any externally supplied data before it may be used by the process. Optimally, these daemons should be run under a grsec kernel that provides additional protections, including making chroots far more bulletproof than they normally are under Linux, but I don't hard fail for lack of that.
The trouble is simply that most developers don't think about these things.
In the meantime I've told you how many Linux-based systems don't use bash as their default shell. The reality being opposite to your arbitrary statement that "the vast majority" of them do.
In terms of the ratio of Linux distributions which use Bash as the default shell versus those that do not, the vast majority still use Bash. As I mentioned earlier, Debian-based distributions use dash as the default system shell, but Bash remains the default interactive shell, and many scripts specify #!/bin/bash in their shebang line.
That last bit is important, because we're living in times where an increasing number of developers are releasing code for network daemons which are designed to be easily run under unprivileged user accounts by those same users. Regardless of how secure the daemons themselves may be, the simple fact that they're executed with Bash as their parent process means they're vectors for system compromise from bugs like Shellshock. Should developers take additional measures to spawn their processes under a different shell? Perhaps, but only if problems like Shellshock are known, and should a similar bug be discovered in the true Bourne shell (or whatever else), we'd still be in the same position.
You should. Its purpose is to override other people's posts when you have something important to say.
The karma bonus posting option is enabled by default for a reason. When people who have an established track record of saying meaningful things (as determined by the up-modded metric) post comments, those comments are automatically ranked higher. Likewise, the moderation system provides for down-modding of any given comment, which has the side effect of karma reduction for the "offending" poster. The fact that you don't like what someone has to say is really of little consequence unless you have mod points; this is by design.
Did he laugh about Debian/kFreeBSD? Did he laugh about OSX? Did he laugh about Cygwin or SUA? No, but he laughed about a minority subset of Linux distributions, and called them "Linux", having an uninformed reader believe that the bug is in Linux (it isn't) or that all Linux distributions are affected (many aren't). He was so aware of this fact, that he posted anonymously.
Let's get a few things straight in terms of my perspective on this whole ordeal. Most of my infrastructure runs on Debian, and the remainder runs on FreeBSD, OpenBSD, and Solaris. I understand your sentiment in feeling offended at this situation being labelled a "Linux problem," and I think the original poster is a positive dickhead for what he wrote. That said, I recognize that the reality of the situation is that around the globe, most of the systems affected by this bug will be Linux-based servers. There's no escaping this fact, as unfortunate as it may be. Given these circumstances, it is very much a "Linux problem," regardless of the fact that the kernel isn't to blame.
For a little perspective, I do infosec for a living (spending a fair amount of my time developing exploits from scratch, in fact), and I'm a senior guy who is intimately involved with promulgating guidance for rapidly patching a ridiculous number of servers against this sort of problem across several datacenters spanning multiple continents. It sucks, but software isn't perfect. We do what we have to do in situations like this and keep moving.
Various common software packages explicitly specify #!/bin/bash in their init (and other) scripts. This is done to prevent problems in cases where the scripts in question must be run under Bash, in recognition of the facts that (1)/bin/sh may be arbitrarily remapped/diverted to any number of shells by system administrators, and (2) alternate shells such as dash are not 100% compatible with Bash.
As a simple example, the shebang line for Zimbra init scripts is #!/bin/bash.
Shellshock isn't really about elevating user account privileges (although that's certainly a common goal once unprivileged shell access is obtained). It's about gaining the ability to execute arbitrary commands as the user a Bash shell is running as. This is particularly bad for systems where the default system shell is/bin/bash, but it's also very bad for systems where users may be running network daemons under a normal user account. This is more common than you might think; developers frequently run things like node.js, various Ruby servers, etc in this manner. In the worst case event that/bin/bash is the default system shell, accounts such as "www-data" or "nobody" will likely use this shell for CGI request handoffs, meaning any input passed through CGI represents an opportunity to send a special payload down the pipe for execution in the context of that user account.
While Bash isn't the default system shell on FreeBSD (nor is it even installed by default), I certainly hope you're at least using "pkg audit" with things you install from the ports collection, as package signing is only just now available with pkgng and it isn't required. If we're going to have a discussion on things related to security, these points should probably be brought up.
Please explain how scripts which specify #!/bin/bash on the shebang line are going to use something else. An awful lot of scripts have that as their first line.
Please reference the output of "echo $SHELL" in your terminal. Unless you've changed it, Bash (via/bin/bash) is still your default interactive shell. You can change your shell if you like.
Part of my last comment was actually wrong, but you probably won't like the reason it was wrong. While Debian and Ubuntu use dash as the default system shell, Bash is still the default interactive (login) shell. Reference the output of "echo $SHELL" at a prompt on a vanilla Debian or Ubuntu server. I'm sure you'll appreciate this, as I agree it's always important to get our facts right. Cheers.
You fail to appreciate the difference between Linux and Bash
Wrong. The difference is clear, but it's also clear you lack any semblance of understanding that terms have implications depending on context. Please tell us all how many Linux-based systems you operate that run only a bare kernel.
You fail to appreciate the fact that no, the most popular Linux distributions don't ship with Bash as the default shell.
Wrong. While Debian and Ubuntu (along with various other Debian derivatives) ship with dash as the default interactive shell, here's a nice (non-exhaustive) list of highly popular distributions which use Bash as the default:
Red Hat
Fedora
openSUSE
Mageia
Arch
Slackware
and the Karma Bonus
Who cares about that?
doing the condescendent and attacking me personally
Wrong. It's not personal, really. I don't care who you are, but I do care that you made an overt attempt at muddying the waters by acting in an overly pedantic fashion, when said pedantry was clearly in error given the context of the discussion. You can always phone RMS up if want to have a nice "omg yes Linux is not GNU and GNU is not Linux" conversation. That particular point has no value in this context, as the discussion here is on complete operating systems, not bare kernels.
then you had better get your facts right
My facts are in order. Are you tired of digging yet? You can always put down the shovel.
Some environments do indeed link/bin/sh to a shell binary of choice. Others use things like dpkg-divert (Debian-based systems) to manage which binaries get run for certain commands, and under FreeBSD default shell selection is typically accomplished via "chsh -s/usr/local/bin/whatevershell" after installing the desired shell (probably via the ports collection). What was your point again?
Please elaborate. I'm deeply troubled by the possibility that my understanding of BSD-based systems might be flawed, since I've been operating a significant amount of infrastructure based on OpenBSD and FreeBSD for over a decade.
No, you're incorrect, and you're making yourself look worse now. Put down the shovel. Let's review, starting with your original post:
FreeBSD is vulnerable to this attack as much as Linux, or Windows. It's a bug in an application, not in the OS.
An "OS" (operating system) is more than a bare kernel, at least for the systems being discussed in this scope, and this is certainly the case for the overwhelming majority of general purpose computers on our planet. "Linux" in this context refers to operating system distributions which include a Linux kernel and various assortments of userland software, much as FreeBSD/Mac OS X/Windows/etc consists of a kernel and other software. Operating systems do indeed have a concept of a default shell, and this may be expressed as simply as a filesystem link from/bin/sh to whatever program is designated as the default, or it may be a default in another sense such as the default shell assigned to a user account upon its creation if no particular login shell is specified.
The default installed set of software (the "applications") will vary between distributions, and if a vulnerable application (Bash in this case) is not installed, the server running said operating system environment cannot be exploited via any vulnerabilities which may exist in that application. If an administrator chooses to install a particular bit of software, the system then may become exposed to security vulnerabilities in said software, but the important distinction being made here is that computers are not vulnerable to bugs for software which isn't installed. Most popular distributions Linux systems install Bash by default, and it is frequently the default shell.
This is really very simple. Are you still having trouble with comprehension? I suspect you may be attempting to act in a pedantic manner here, but you're doing a poor job of it if that's the case.
While my personal observations in this context are overwhelmingly in agreement with yours, I'll add that there is a subtle difference between office cultures which display visceral disdain for formality and those which merely disregard it as being irrelevant to the core mission of the business. The former may be summarized as "damn the man, we're hip and trendy and full of venture capital, and can you please repeat the question" whereas the latter may be closer to "the attire of a particular group of people only becomes a relevant factor if a strong correlation between utility/intelligence/incompetence is simultaneously noted, and said correlation should not necessarily be assumed to extend to other groups of people."
Given that you bothered to reference "lenght (sic) of time," I find it disheartening that you have also demonstrated apparent failure to comprehend or intelligently consider bounding problems, population density, transmission risks and rates, practical effects of seemingly low mutation rates, microbiology, and systems thinking. In short, all activities involving large scale administration of antibiotics to livestock at dosages resulting in appreciable treatment/prevention efficacy are practices which drive substantial and increasing risks to public health.
The math doesn't lie, and the trending curves of probabilities associated with widespread epidemics aren't exactly uplifting. I'll make a preemptive recommendation that you suppress the urge to post anything resembling a cliché "citation needed" response here. Given the circumstances at hand, devotion of your time to even a cursory review of the aforementioned subject matter would likely be a more productive activity. Such study will necessarily involve your review of all citations referenced in said materials, review of nested citations, etc. You wouldn't want to compound foolishness with yet more foolishness, would you?
I'm willing to admit that I may be entirely wrong in my assessment of your level of knowledge, with the corollary that you are simply betting that your benefits will outweigh your risk in this area for the duration of your lifespan. However, given that I know nothing of your mode of living or the measures of your personal resource reserves on hand for reaction/relocation/adaptation/insulation in response a large scale communicable disease crisis, I must hazard a guess that you're either (A) dangerously ignorant of reality or (B) very well prepared to deal with things turning shitty in a hurry. It is my measured estimation that the odds of your membership in the intersecting set are quite low, given your mid-range UID and the generally incongruous nature of the respective attributes of the A and B sets.
If you work in any field involving network infrastructure, software development, information services, or data management/warehousing and your salary is at all dependent upon your attire, I strongly suggest you inquire with competing firms. You may well find they're paying better and place fewer arbitrary burdens upon their personnel.
Every professional workplace has an expectation of a formal atire. What is wrong with requiring suits over the usual office shirts and pants?
I'm not opposed to wearing a well-tailored suit. I've worn many suits over the years, and I once wore a Navy uniform for a living. These facts notwithstanding, your view on this topic is plainly distorted. My professional workplace doesn't have this expectation, and our average employee salary is considerably higher than that of a great many companies with dress codes. Our expectations are that reasonable personal hygiene is attended to and that our employees bring brains and dedication to work every day. As for clothes, the policy is generally "yes, please, nudity might be distracting." This workplace is a rather large, professionally designed, thoughtfully laid out office space. Lunch is also catered every day. You might be doing it wrong.
Slashdot Mirror
As a side note, if our hypothetical programmer merely examines and untaints $ENV{PATH} in the last example, the exploit will succeed, since Perl doesn't do any taint inspection of a string passed to system() unless it interpolates potentially tainted input. Still, a reasonable programmer would hopefully have an "ah ha" moment after being reminded that $ENV{PATH} is tainted and consider the rest of the environment.
I completely agree.
I don't think you're being argumentative at all. Your points are fair and valid, and I'll note that the specific example provided (per the comments embedded in it) is a bit on the contrived side. That said, Perl actually used to just use whatever it found in $ENV{SHELL} for system() calls, which would have removed the necessity of including the explicit /bin/bash call to trigger the bad behavior, but that behavior was fixed some time ago. Other programming languages and environments may be quite a bit more lax, shifting more of the security burden onto the general operating system environment and further abstracting unsafe lower-level calls away from the programmer.
However, the earlier example is still quite useful for demonstrating another Perl best practice: taint mode. I have seen some truly dreadful things done via shell-outs in various languages, because programmers are of course capable of doing all sorts of very silly and dangerous things in their programs (such as including direct shell binary invocations in system calls), frequently without realizing those things are that dangerous in context. This may be due to the dangers being difficult to anticipate, and this could be said of our first example, as it doesn't contain any code that visibly uses external data. Here's what happens when we turn on taint mode in the initially exploitable script: Perl taint mode saves lives.
If I get the time, I'll be setting up various test environments with an assortment of examples written in different languages and frameworks to demonstrate the sorts of differences described herein, and I'll be glad to keep you posted if you like.
I'm perfectly capable of fixing things myself. That's not the issue here. Try enforcing the policy you described across even a moderately sized multi-tenant SMB computing environment running a variety of applications that you're responsible for managing. You'll soon find that your policy results in negative revenue. The end result becomes a case study in "you broke it, they stopped buying it."
I put together a small example for you.
The Zimbra example is only a single case intended to illustrate the mere existence of #!/bin/bash in scripts on commonly deployed systems; there are many, many others to be found, including wrappers for various commonly used utilities than may well wind up being called from a CGI script. As for your last sentence, you're conflating two concepts. I was specifically addressing the following response: "Certainly not in a distribution which does not have bash as the system shell. You can uninstall bash in such a distribution, and the system is expected to continue running." See the difference?
I'll add a note that a couple of network daemons I've recently authored are designed to be started under any given shell, including Bash, but they also communicate over raw TCP sockets instead of CGI, get exec-ed into a shell with an explicitly blank environment (blank as in "no environment vars are set whatsoever"), chroot themselves to a safe filesystem with noexec specified for the mount, drop privileges to "nobody" (again, with no env vars available and hence nothing for the shell to parse), mlock their process memory, and run under Perl's hard taint mode which requires regex whitelist examination of any externally supplied data before it may be used by the process. Optimally, these daemons should be run under a grsec kernel that provides additional protections, including making chroots far more bulletproof than they normally are under Linux, but I don't hard fail for lack of that.
The trouble is simply that most developers don't think about these things.
In the meantime I've told you how many Linux-based systems don't use bash as their default shell. The reality being opposite to your arbitrary statement that "the vast majority" of them do.
In terms of the ratio of Linux distributions which use Bash as the default shell versus those that do not, the vast majority still use Bash. As I mentioned earlier, Debian-based distributions use dash as the default system shell, but Bash remains the default interactive shell, and many scripts specify #!/bin/bash in their shebang line.
That last bit is important, because we're living in times where an increasing number of developers are releasing code for network daemons which are designed to be easily run under unprivileged user accounts by those same users. Regardless of how secure the daemons themselves may be, the simple fact that they're executed with Bash as their parent process means they're vectors for system compromise from bugs like Shellshock. Should developers take additional measures to spawn their processes under a different shell? Perhaps, but only if problems like Shellshock are known, and should a similar bug be discovered in the true Bourne shell (or whatever else), we'd still be in the same position.
You should. Its purpose is to override other people's posts when you have something important to say.
The karma bonus posting option is enabled by default for a reason. When people who have an established track record of saying meaningful things (as determined by the up-modded metric) post comments, those comments are automatically ranked higher. Likewise, the moderation system provides for down-modding of any given comment, which has the side effect of karma reduction for the "offending" poster. The fact that you don't like what someone has to say is really of little consequence unless you have mod points; this is by design.
Did he laugh about Debian/kFreeBSD? Did he laugh about OSX? Did he laugh about Cygwin or SUA? No, but he laughed about a minority subset of Linux distributions, and called them "Linux", having an uninformed reader believe that the bug is in Linux (it isn't) or that all Linux distributions are affected (many aren't). He was so aware of this fact, that he posted anonymously.
Let's get a few things straight in terms of my perspective on this whole ordeal. Most of my infrastructure runs on Debian, and the remainder runs on FreeBSD, OpenBSD, and Solaris. I understand your sentiment in feeling offended at this situation being labelled a "Linux problem," and I think the original poster is a positive dickhead for what he wrote. That said, I recognize that the reality of the situation is that around the globe, most of the systems affected by this bug will be Linux-based servers. There's no escaping this fact, as unfortunate as it may be. Given these circumstances, it is very much a "Linux problem," regardless of the fact that the kernel isn't to blame.
For a little perspective, I do infosec for a living (spending a fair amount of my time developing exploits from scratch, in fact), and I'm a senior guy who is intimately involved with promulgating guidance for rapidly patching a ridiculous number of servers against this sort of problem across several datacenters spanning multiple continents. It sucks, but software isn't perfect. We do what we have to do in situations like this and keep moving.
Various common software packages explicitly specify #!/bin/bash in their init (and other) scripts. This is done to prevent problems in cases where the scripts in question must be run under Bash, in recognition of the facts that (1) /bin/sh may be arbitrarily remapped/diverted to any number of shells by system administrators, and (2) alternate shells such as dash are not 100% compatible with Bash.
As a simple example, the shebang line for Zimbra init scripts is #!/bin/bash.
Shellshock isn't really about elevating user account privileges (although that's certainly a common goal once unprivileged shell access is obtained). It's about gaining the ability to execute arbitrary commands as the user a Bash shell is running as. This is particularly bad for systems where the default system shell is /bin/bash, but it's also very bad for systems where users may be running network daemons under a normal user account. This is more common than you might think; developers frequently run things like node.js, various Ruby servers, etc in this manner. In the worst case event that /bin/bash is the default system shell, accounts such as "www-data" or "nobody" will likely use this shell for CGI request handoffs, meaning any input passed through CGI represents an opportunity to send a special payload down the pipe for execution in the context of that user account.
While Bash isn't the default system shell on FreeBSD (nor is it even installed by default), I certainly hope you're at least using "pkg audit" with things you install from the ports collection, as package signing is only just now available with pkgng and it isn't required. If we're going to have a discussion on things related to security, these points should probably be brought up.
Please explain how scripts which specify #!/bin/bash on the shebang line are going to use something else. An awful lot of scripts have that as their first line.
Please reference the output of "echo $SHELL" in your terminal. Unless you've changed it, Bash (via /bin/bash) is still your default interactive shell. You can change your shell if you like.
Part of my last comment was actually wrong, but you probably won't like the reason it was wrong. While Debian and Ubuntu use dash as the default system shell, Bash is still the default interactive (login) shell. Reference the output of "echo $SHELL" at a prompt on a vanilla Debian or Ubuntu server. I'm sure you'll appreciate this, as I agree it's always important to get our facts right. Cheers.
You fail to appreciate the difference between Linux and Bash
Wrong. The difference is clear, but it's also clear you lack any semblance of understanding that terms have implications depending on context. Please tell us all how many Linux-based systems you operate that run only a bare kernel.
You fail to appreciate the fact that no, the most popular Linux distributions don't ship with Bash as the default shell.
Wrong. While Debian and Ubuntu (along with various other Debian derivatives) ship with dash as the default interactive shell, here's a nice (non-exhaustive) list of highly popular distributions which use Bash as the default:
and the Karma Bonus
Who cares about that?
doing the condescendent and attacking me personally
Wrong. It's not personal, really. I don't care who you are, but I do care that you made an overt attempt at muddying the waters by acting in an overly pedantic fashion, when said pedantry was clearly in error given the context of the discussion. You can always phone RMS up if want to have a nice "omg yes Linux is not GNU and GNU is not Linux" conversation. That particular point has no value in this context, as the discussion here is on complete operating systems, not bare kernels.
then you had better get your facts right
My facts are in order. Are you tired of digging yet? You can always put down the shovel.
Some environments do indeed link /bin/sh to a shell binary of choice. Others use things like dpkg-divert (Debian-based systems) to manage which binaries get run for certain commands, and under FreeBSD default shell selection is typically accomplished via "chsh -s /usr/local/bin/whatevershell" after installing the desired shell (probably via the ports collection). What was your point again?
Please elaborate. I'm deeply troubled by the possibility that my understanding of BSD-based systems might be flawed, since I've been operating a significant amount of infrastructure based on OpenBSD and FreeBSD for over a decade.
No, you're incorrect, and you're making yourself look worse now. Put down the shovel. Let's review, starting with your original post:
FreeBSD is vulnerable to this attack as much as Linux, or Windows. It's a bug in an application, not in the OS.
An "OS" (operating system) is more than a bare kernel, at least for the systems being discussed in this scope, and this is certainly the case for the overwhelming majority of general purpose computers on our planet. "Linux" in this context refers to operating system distributions which include a Linux kernel and various assortments of userland software, much as FreeBSD/Mac OS X/Windows/etc consists of a kernel and other software. Operating systems do indeed have a concept of a default shell, and this may be expressed as simply as a filesystem link from /bin/sh to whatever program is designated as the default, or it may be a default in another sense such as the default shell assigned to a user account upon its creation if no particular login shell is specified.
The default installed set of software (the "applications") will vary between distributions, and if a vulnerable application (Bash in this case) is not installed, the server running said operating system environment cannot be exploited via any vulnerabilities which may exist in that application. If an administrator chooses to install a particular bit of software, the system then may become exposed to security vulnerabilities in said software, but the important distinction being made here is that computers are not vulnerable to bugs for software which isn't installed. Most popular distributions Linux systems install Bash by default, and it is frequently the default shell.
This is really very simple. Are you still having trouble with comprehension? I suspect you may be attempting to act in a pedantic manner here, but you're doing a poor job of it if that's the case.
You're incorrect. The default shell is tcsh on FreeBSD, and bash isn't even installed by default.
I'm working on some rather large scale parallel network operations, btw.
I suspect we'd get along pretty well. Hit me up if you're ever in Dallas, TX.
While my personal observations in this context are overwhelmingly in agreement with yours, I'll add that there is a subtle difference between office cultures which display visceral disdain for formality and those which merely disregard it as being irrelevant to the core mission of the business. The former may be summarized as "damn the man, we're hip and trendy and full of venture capital, and can you please repeat the question" whereas the latter may be closer to "the attire of a particular group of people only becomes a relevant factor if a strong correlation between utility/intelligence/incompetence is simultaneously noted, and said correlation should not necessarily be assumed to extend to other groups of people."
Given that you bothered to reference "lenght (sic) of time," I find it disheartening that you have also demonstrated apparent failure to comprehend or intelligently consider bounding problems, population density, transmission risks and rates, practical effects of seemingly low mutation rates, microbiology, and systems thinking. In short, all activities involving large scale administration of antibiotics to livestock at dosages resulting in appreciable treatment/prevention efficacy are practices which drive substantial and increasing risks to public health.
The math doesn't lie, and the trending curves of probabilities associated with widespread epidemics aren't exactly uplifting. I'll make a preemptive recommendation that you suppress the urge to post anything resembling a cliché "citation needed" response here. Given the circumstances at hand, devotion of your time to even a cursory review of the aforementioned subject matter would likely be a more productive activity. Such study will necessarily involve your review of all citations referenced in said materials, review of nested citations, etc. You wouldn't want to compound foolishness with yet more foolishness, would you?
I'm willing to admit that I may be entirely wrong in my assessment of your level of knowledge, with the corollary that you are simply betting that your benefits will outweigh your risk in this area for the duration of your lifespan. However, given that I know nothing of your mode of living or the measures of your personal resource reserves on hand for reaction/relocation/adaptation/insulation in response a large scale communicable disease crisis, I must hazard a guess that you're either (A) dangerously ignorant of reality or (B) very well prepared to deal with things turning shitty in a hurry. It is my measured estimation that the odds of your membership in the intersecting set are quite low, given your mid-range UID and the generally incongruous nature of the respective attributes of the A and B sets.
If you work in any field involving network infrastructure, software development, information services, or data management/warehousing and your salary is at all dependent upon your attire, I strongly suggest you inquire with competing firms. You may well find they're paying better and place fewer arbitrary burdens upon their personnel.
Every professional workplace has an expectation of a formal atire. What is wrong with requiring suits over the usual office shirts and pants?
I'm not opposed to wearing a well-tailored suit. I've worn many suits over the years, and I once wore a Navy uniform for a living. These facts notwithstanding, your view on this topic is plainly distorted. My professional workplace doesn't have this expectation, and our average employee salary is considerably higher than that of a great many companies with dress codes. Our expectations are that reasonable personal hygiene is attended to and that our employees bring brains and dedication to work every day. As for clothes, the policy is generally "yes, please, nudity might be distracting." This workplace is a rather large, professionally designed, thoughtfully laid out office space. Lunch is also catered every day. You might be doing it wrong.