Namespaces basically are a sort of kernel enforced isolation. A processes enters a namespace and to that process it might be root on its own machine. Behind the scenes the kernel is kinda translating everything it does so into its own little sandboxed area instead of the root system. But inside that namespaces it legitimately thinks it is the root user and can exercise most of the functional that is only exposed to privileged users. (f course the kernel limits what it can do to only being inside it’s own little space so that alone isn’t an issue.

When it comes to hardening, the namespaces are not inherently insecure. The difference is in the “attack surface” an unprivileged user has access to through them.

A simple example of this is mounting a filesystem. Now the user won’t be able to like remount a privileged filesystem or something it’ll be isolated. But let’s say there is a vulnerability in the exact filesystem code in the kernel, your server doesn’t mount any exfat drives and you disallow automounting of anything for hardening. So even if the issue exists an attacker couldn’t exploit it because the exfat code isn’t reachable as normal user. With a user namespaces though a user becomes root of their own little area so they can actually ask the kernel to mount something inside their namespace. So now with a namespace an attacker can get access to exploit their theoretical exfat filesystem vulnerability.

tl;dr the problem with having namespaces on is it allows unprivileged users access to a lot more “potentially” vulnerable code that could be exploitable.

the school I’m transferring to has a cybersecurity degree designed to pick up where my AS leaves off.

(Disclaimer, I’m speaking from US and Canada based experience)

Be careful with CyberSecurity programs; it sounds great but there is no standard regarding what a cybersecurity degree even should be. Which means every place offering one can do whatever they want. Some programs are fine, some are lacking, regardless you have to make sure its actually preparing you for whatever part of security you’re actually interested in. It also means that on the hiring side, people won’t know exactly what its value is without looking into your specific program (which they probably won’t do). Which puts it at a lesser value than a more predictable degree. Still often acceptable at least but worth calling out.

If you’re new I’d also strongly encourage you to learn about different facets of cyber security; it is an absolutely massive field and different areas have different expectations. A lot of people have a misunderstandings about security jobs look like.

These are in no particular order, just thinking back over some that I’ve read in recent years.

• The Cuckoo’s Egg - Really interesting book about running a honeypot and trying to tracking down a hacker who was stealing resources from Lawrence Berkeley Lab machines. Its based on actual events has some fun insights into the tech of the time and it had a fairly gripping plot despite the age.

• Cult of the Dead Cow - First while of this book was just history and stories about the cDc from its members. From the joining of key members and becoming a hacking group, then into its hacktivism and more professional work. The later parts of the book tie into Beto O’Rourke (who was part of the cDc) political campaign and the tone kinda shifts a bit. Wasn’t like it ruined the book or something, but it was a distinct shift in tone different from the parts that hooked me into it.

• The Hacker and the State - This was a look at effectively cyberwar through the years and how/why it hasn’t really turned out how people predicted being less destructive but more pervasive. Kinda gave a good, as far as I can tell fact-based perspective on the geopolitics of cyberattacks and how its developed.

• Dark Territory: The Secret History of Cyber War - Similar concept to The Hacker and the State but more narrow focus. Just looking at the development of cyber-capabilities and use in the US.

• No Place to Hide - Okay, maybe not exactly computer security related. Its more the behind the scenes of the Snowden leaks. Obviously the leaks do touch on security and they talk about their opsec in communicating before actually meeting. That behind the scenes aspect was most interesting to me, but it did go into what was leaked and such also. I’ll also shout out Permanent Record which just ties in nicely with No Place to Hide. Its Snowden’s memoir.

• Little Brother - So this one isn’t on audible as the author Cory Doctorow is outspoken against the DRM systems. Its a fictional book following a high-school student who becomes a reluctant hacker for civil liberties and privacy. The cool thing about the book is that it accurately represents technology, and explains things like how TOR works, about public key crypto, VPNs, etc; and it does so accurately, albeit sometimes superficially. I’ve done a poor job summarizing but Mudge at DefCon 21 mentioned the book is used as training material at the NSA to give recruits a different point of view. Bruce Schneier and Andrew “bunnie” Huang both have essays included as afterwords in the book which you wouldn’t usually find in a fictional hacking book. It definitely captures some of the counter-cultural ideals that existed in the hacking community in the mid-00s and earlier. Even though its not on audible I’d still recommend it.

That is generally what I’d recommend, and have liked seeing in a resume.

My thinking is that seeing projects tends to showcase not just a particular skill like with a language you used, but shows an understanding of the problems facing some area that your project is trying to solve. I’ve never really been a fan of skills listings just because they offer basically no context. Whereas projects give me something to bounce off of in an interview, and hopefully get the candidate talking.

I will say though that I wasn’t the person reviewing resumes deciding who got an interview, I’ve just been an interviewer after someone made it through the screening.

Figured I’d expand on something Alex said in response to you.

Client side should not hash the password which I am fairly sure would allow pass-the-hash, but don’t quote me on that.

Basically hashing it on the client doesn’t solve the problem it just shifts it a bit. Instead of needing to capture and then send the plaintext password to the server. An attacker would simply need to capture and send the hash as generated by the client to the server. In both cases an attacker with access to the plain communication between client and server would have all the information necessary.

Basically if you hash it on the client-side, you’ve just made the hash the password that needs to be protected as an attacker only needs to “pass the hash” to the server.

That said you are raising a legitimate concern and its a great question that shows you’re starting to think about the issues at hand. Because, you’re right. When we send the password in plaintext at the application layer we are simply trusting that the communication channel is secure, and that is not a safe assumption.

There is a bit of a rabbit hole regarding authentication schemes you can dive into and there is a scheme that adds a bit more onto the simple idea of just hashing the password on the client-side. Basically, the server provides a nonce (a one-time use value) to the client. The client hashes their password with this nonce included and sends the resultant hash back to the server to be validated. It kinda solves the issue of someone being able to read the communication as the hash being sent over the wire is only useful in response to that specific nonce for that specific user.

The trade-off on this is that in-order for the server to be able to validate the response from the client, the server must have access to that same key-data the client hashed with the nonce, AKA passwords needs to be stored in a recoverable way. You increase security against a compromised communication channel, but also increased the damage that an attacker could do if they could leak the database.

Going further down the rabbit hole, there is Salted Challenge-Response Authentication which takes a step towards alleviating this by storing a salted and hashed version of the password. And then providing the client the nonce as usual along with the salt and other information needed for the client to reproduce the version of the hash the server is storing. This does mean passwords are not in “plaintext” but it has in effect made the hashed version the password that should be protected. Anyone who compromises the database still has all the information necessary to generate the response for any nonce. They just couldn’t try for password reuse stuff like one could if it was actually recoverable.

Ultimately, this comes down to what is the bigger threat. You can (somewhat) secure against a compromised communication channel (which is generally a targeted attack against only one user at a time), but it means that some server side vulnerabilities will be able to compromise every user account. In general, for web-apps I think you’re better off hardening the server-side and having mitigations like 2FA around sensitive actions to limit the damage just compromising the password could do.

Also, if you really wanted to be more secure against communication channel issues, public key cryptography is a better tool for that, but has generally not be well supported for web-apps.