#system administration

[gay-systemdeez]

My linux system administration teacher literally looks like the stereotypical linux user lmao.

[signalcli]

Security, Security… The SSL Story

“We have to get our trust center going IMMEDIATELY!” “YES SIR”, we replied. Pulling aside the IT director, we started discussing what that really meant. One thing led to another, and before we knew it, we found ourselves reminiscing over a few beers…

Rip-off of the 21st Century: How Google Boosted the SSL Industry

Let’s rewind a bit, back to 2010. Dinosaurs weren’t roaming, cars were everywhere — not perfect, sure, but good enough.

Website security was straightforward. Regular websites? Chill, nothing special needed. Websites with logins? SSL was sensible — encrypt usernames and passwords, simple logic. E-commerce sites? Checkout security was a no-brainer. Simpler times indeed — our IT director once casually received over 50,000 credit card details via email (password-protected, naturally!) during a site migration.

Google faced occasional ranking confusion — sites existed as HTTP, HTTPS, www, and non-www versions. A small mess, but manageable and amusing.

Then, suddenly, 2011 arrived. Rumors started swirling: “Google rewards fully HTTPS sites!” Interesting, right? No actual security improvement required, just better SEO rankings and more visitors.

Fast-forward another year: HTTPS became mandatory. Browsers like Chrome began labeling non-HTTPS websites “unsafe,” although security wasn’t the primary reason — more a convenience thing. And certainly not the user’s convenience.

More Encryption, More Resources, More Profits

Encryption — required to support secure communication — isn’t free; it demands additional resources. Additional resources translated into requirements for larger, more expensive servers. Encryption doesn’t merely happen on the server; someone has to decrypt it. While desktops hardly noticed the difference, smartphones certainly did — demanding noticeably more RAM and CPU power. Hardware upgrades surged. SSL certificates became lucrative businesses overnight. Suddenly, free certificates from “letsencrypt” weren’t “good enough.” Companies shelled out money for essentially identical commercial SSL certificates, boosting profits for hosting providers, certificate issuers, and smartphone manufacturers. But wait, there’s more…

New Standards, Same Old Devices

A few years later came newer TLS standards — 1.0 to 1.3. Were newer versions significantly more secure? Only marginally, closing theoretical and academic vulnerabilities never exploited. Yet enforcing standards like TLS 1.2 and 1.3 forced users with older hardware — devices unable to support these new standards — to upgrade unnecessarily, funneling even more profits into the tech industry without boosting real-world security.

Security scanners? Oh god, we absolutely loved those. Our IT director regularly received dozens of panicked emails: “OMG our site is not secure, please help us fix it!” Yet, examining the scan details typically revealed only one “vulnerability”: support for perfectly functioning TLS 1.0. Occasionally, scanners were ordered without proper heads-up, causing our automated security systems to block them immediately. Another flurry of emails followed: “Please unblock our security scanner — it’s unable to scan the website!” But wait — if security was the goal, wasn’t blocking unknown scanners a good thing? “WRONG,” said corporate bosses, demanding immediate unblocking. Logic had officially left the chat…

The Reality of Our Trust Center

This brings us back to our Trust Center dilemma. Our SignalCLI platform’s security rivals Fort Knox. Logging in? Like walking between skyscrapers on a tightrope during a hurricane — fingerprints, selfies, the whole nine yards. Getting information out? Not exactly possible.

Yet, after lengthy debates, we recognized the need for “paperwork security” — documentation and policies designed mainly to appease compliance folks. Welcome to 21st-century security: installing antivirus software on Linux systems — completely unnecessary but required on paper. Bureaucratic security, not practical security.

Now, we’re proud owners of our Trust Center, complete with extensive paperwork that few read but compliance teams adore.

It reminded our IT director of another story, which I’m sure he won’t mind me sharing. A couple of decades ago, he was working for an international company and, wanting to know who he was hiring, insisted on participating in interviews. A candidate walked in, applying for a senior developer position.

“How’s your English?” our IT director asked.

“I have an upper-intermediate level,” the candidate replied confidently, proudly handing over his certificate.

Our IT director (a multilingual guy — and yes, I’m jealous) switched to English: “So, can you continue the interview in English?”

Silence. The candidate couldn’t understand or respond in English. But he had a certificate — that’s the important part, right?

Final Thoughts

Real security matters. Bureaucracy? Not so much.

Still, quite the SSL story, isn’t it?

Be good out there!

Enjoying the content? Awesome! If you’d like to support me, you can send USDT (BEP20) to the wallet below: 0x7241275b9D37CcF0621480fD408CFf401762c485 Your support keeps content free and accessible to everyone — thanks!

[fossguy]

How much RAM in your Linux PC?

512MB

<1GB

1GB

2GB

4GB

8GB

16GB

32GB

64GB

96GB

128GB

Voting ended onApr 16

[masquerade-flags]

Persecutory Administrator, Janusian Administrator

Persecutory Administrator - An alter that has a high degree of control over the system(or specific subsystem or layer) and system functions, that uses this power predominately to harm the system or specific alters.

Janusian Administrator - An alter that has a high degree of control over the system(or specific subsystem or layer) and system functions, that uses this power to both harm and help the system. Or the actions of a Janusian Administrator help the system in some ways and hurt the system in others.

[myzanilred]

The Secret Fourth Thing: UNIX Special File Permissions, File Types, and Swap

In my recent post on number systems, I talked about octal, and its use in UNIX file permissions. I mentioned the three permissions: read, write, and execute, as well as the three permission groups: user, group, and other. I explained how these values were encoded as octal values, how to read them, and how to determine access rights to files.

I also mentioned in that article, a fourth group of permissions, but elected not to discuss it at the time. While it doesn't relate to any current projects, I still believe it's worth mentioning this extra group, and their purpose. So, to that end, I'm taking the time here to discuss them, in detail.

Don't worry, there's no maths in this one.

The Special Permissions Group

Most files on UNIX-like systems use only the main three permission groups. However, sometimes a file (usually an executable) needs to inform the system of some special condition regarding its access.

In order to accommodate these special cases, a fourth group of permissions, which is typically written to the left of the three regular groups, in octal, (04755, 02755, 01640, etc.), or as a special character in the execute permission field of the textual representation ("-rws------", "-rwxr-s---", "-rwxr-xr-t", etc.).

Unlike the other three groups, the special permissions are modifiers, not directly controlling user's access to the files, but how those accesses behave. From left to right, they are the setuid bit, setgid bit, and sticky bit. The exact behavior of these modifiers may differ slightly between systems, and between file types.

Lets start by getting file types out of the way.

UNIX File Types

Not to be confused with the file formats/encoding, like text, JPEG, MP3, ELF binary, etc. that we usually call "file types", UNIX file types refer to the different types of virtual files that the operating system provides. These different types may not correspond to files on disk, and, in fact, may not even exist in the filesystem tree at all! These include:

Regular files, which usually exist in the filesystem tree, and contain either text, or binary data.

Directories, which exist in the filesystem tree, and contain file node listings that make it possible for files within a filesystem to be located and referenced. They also serve as mount points, where additional filesystems may be attached to extend the current tree.

Symbolic links, aka. symlinks, which allow a file to be referenced in multiple locations in the filesystem tree, without needing to create separate copies, or creating additional references to the file within the filesystem (hard linking). They essentially contain the path to an actual file, and opening them is treated like opening the file at the path they reference, assuming the file exists.

Block devices, which are physical, or virtual, devices which (to the kernel, at least) are accessed in fixed sized blocks. Usually these include storage devices, like floppy disks, hard disks, solid-state storage, and RAM disks.

Character devices, which are physical, or virtual, devices that read and/or write data, one character (byte) at a time. These often include serial devices, and HIDs (Human Interface Devices), like keyboards, pointing devices, and joysticks/gamepads.

Sockets, which are virtual files that refer to connections in the OS's network stack, including general network connections, and IPC (inter-process communication) connections over UNIX domain sockets.

Pipes, sometimes called FIFOs, which are virtual files that allow for simple, one-way IPC. Unlike sockets, they are not usually a part of the network stack, instead usually using a simple buffer inside the kernel.

These are the file types seen in the first character of the textual permissions ('-' for a regular file, 'd' for a directory, 'l' for a symlink, etc.).

At the moment, we only need to worry about the first two types, but it's good to know that the others exist, and what they're for.

We'll come back around to how these types fit into our discussion. For now, just keep in mind that directories and regular files are distinct types, with unique properties within the OS.

The setuid Bit

Lets start with the first, and most infamous, of the special permission bits.

The setuid bit plays a very important role in UNIX-like systems, as it enables a program to assume the authority of the user that owns its executable.

That has some rather severe implications, so let's take a look at the most common way this is used.

It's not terribly uncommon for a program to need access to resources that are protected in some way. For example, some implementations of the 'ping' command need access to a raw (or equally low-level) network socket, in order to send the ICMP packets that it uses to determine if a target is accessible. However, normal users aren't permitted to open such sockets, as they would allow a user to forge any kind of network connection they wished, which would definitely be an issue. So how does ping get around this?

First, user IDs. User IDs, or UIDs, are the unique number assigned to each user on a *nix system. They are how the system identifies what user a process is running as, and what user owns any given file. The special UID zero (0), is always the root user, the "god account", which has unrestricted access to all resources.

Processes, which are running instances of a program, actually have three UIDs that are associated with them. By default, these are typically all set to the UID of the user that started the process, and that process is restricted to the permissions granted to that user. However, if a user starts a program owned by another user, that has the setuid bit set on its executable, then the new process will have an effective UID (EUID) of the user that owns the program.

Guess which all-powerful account owns the ping program!

So, if ping is owned by root, and has the setuid bit set, then it can open a raw socket, even if the user running it isn't root. Cool! That solves our problem then?

Well yes, but there's a rather serious problem.

Programming is messy. Errors can be introduced, and go unseen for long periods of time. Some of these errors have the potential to allow a malicious actor to introduce code that wasn't originally part of the program. If that program happens to be a root-owned, setuid program, that can mean the entire system, and any other system running a version of the same program that has the bug, is now vulnerable to what's known as a privilege escalation attack. In fact, this has actually happened with none other than the ping utility, and led to real damage!

While the methods for these attacks, and the exact mechanism for how setuid binaries try to mitigate this risk are well beyond this discussion, I cannot stress enough that setuid is dangerous, and its use should not be taken lightly! It is because of the risk of abuse that most systems restrict the use of setuid to compiled binary programs, and ignore it for scripts.

The easiest way to avoid the risks of setuid is simply to find another way to acquire the needed resources. This is what newer versions of the ping command tend to do (on Linux, at least). However, for some programs, like 'sudo', which allows users with the appropriate privileges to assume the authority of root (or other users), there are no other options.

Now that we understand setuid, we should be able to easily make sense of its somewhat lesser known counterpart.

The setgid Bit

If you were guessing from what you've read here, so far, that the setgid bit is exactly like setuid, except that it sets the effective group, you are absolutely correct.

Just like UIDs, GIDs (group IDs) are the unique integer values assigned to groups. Setting the setgid bit on a program will have the same effect on the group of a process started from that program, as the setuid bit has on the UID, setting the effective GID (EGID) of the new process. This also means that it has all the same issues as setuid, if less immediately dangerous, as the enforcement of group permissions tend to be more strict, even for the root group. Not to say that it's any less of a security risk.

However, if that were all, I could have combined this with the previous section, and moved on. Many systems today give extra meaning to the setgid bit, particularly when is is applied to a directory.

Under normal circumstances (except on BSD systems), when a process creates a new file, that file will inherit the EUID and EGID of the process that created it. This is usually reasonable, but consider a scenario where every user on a system has their own dedicated, primary group, with the same name as their username, while also being members of the shared "user" group (groups that a user is a member of that aren't their primary group are called "supplementary groups"). Because that each user's dedicated group is their primary group, it will be the EGID of any process they start, unless they deliberately switch their active GID (which is something you can do, but it requires deliberate action).

Imagine, now, that all users on our hypothetical system are collaborating on a project in a shared directory which is owned by the shared "user" group. Any user can access this directory, and any user can modify its contents, assuming that those contents have the group set correctly. But, if a user were to create a new file in this directory, by default, it would be created with the user's EGID, which, again, is their own, dedicated group, blocking others from accessing the file, until the group is changed. This is less than ideal.

What if we had some way to signal the OS that we want the contents of a directory to always inherit the GID of the directory (the BSD way)?

This is exactly what setting the setgid bit on a directory allows us to do. Any new files will be created with the same GID as the directory, and any new directories will inherit, not just the GID, but the setgid bit, as well.

In our above example, all we need to do is set the setgid bit on the project directory, and everyone will be able to collaborate happily, without needing to worry about their EGID.

Of course, not all *nixes may support this option. It's also not the only extension of this bit. Linux, for example also extends the setgid bit to indicate mandatory file locking for files where the group execute permission isn't set. But don't worry to much about that nonsense.

Lets look at the last, least understood, and strangest of the special permissions.

The Sticky Bit

Unlike the other two special permissions, that name likely tells you nothing about what this bit does.

What on earth does it mean by "sticky"?

History Time!

Let us consider the time when UNIX was originally being developed.

From the late '60s, to well into the '80s, storage was slow. Tapes were effectively useless for general storage, hard drives and drums existed, but were large, expensive, and still tended to be a significant bottleneck, especially under heavy load.

The fact that the very concepts of operating systems and filesystems were, themselves, still quite new, also meant that many of the features we take for granted today didn't yet exist. Your system might, in worst-case conditions, take twice as long to locate the file you want, on disk, as it takes to seek to the file, and actually read it into memory!

To try and reduce the impact of slow storage and filesystems on commonly used programs, the sticky bit was added, as a way to inform the OS that it should keep a specific file convenient, as it will likely be needed frequently.

Note that I say, "convenient", and not, "in-memory".

While some of these early systems had surprisingly large memory options, for the time, many likely didn't have the full memory configuration, and even that often wasn't enough for busy systems working on many large datasets.

RAM was scarce, and expensive (not unlike today, but actually still far worse). It wasn't uncommon to simply run out of free memory. We even still encounter this today! But, we came up with a neat trick to help get around it.

By this time a neat new architectural feature known as "virtual memory" was beginning to become more prevalent. The details of virtual memory are something I intend to cover, in-depth, at a later date. For now, we just need to know that it presents two advantages:

It allows a userland program to pretend that it has the entire address space of the machine to itself, as though it were the only running program.

It allows the kernel to extend the address space beyond the capacity of physical memory.

That second one is especially important. Virtual memory works by breaking a system's memory into units (either fixed sized units, called pages, or dynamically sized units, called segments). These units may be marked by the the kernel as being either, currently in RAM, or not. If a unit isn't in memory when a program tries to access it, the kernel can decide what it actually wants to do. Using this technique, when a system begins to run out of memory, the OS can push things that aren't currently being used, like say, the text of a program (the executable part of a program that the OS loads into memory to start a process) with the sticky bit set, that hasn't been run in a while, and write it to something like a hard disk.

Wait, didn't we just say that hard disks are slow? How does that help us?!

Well, we also said that a notable potion of that slowness has to do with searching through the filesystem. Units of memory written to the disk aren't a part of the filesystem, they're written to a special area called the "swap" ("pagefile" on Winblows). This area doesn't use a filesystem at all. Instead the unit's locations in the swap are often stored in the same map used to determine if a unit is in memory, making locating them much faster.

Modern OSs have many more tricks up their sleeves, including automatic caching of commonly accessed files, faster storage, and, of course, better filesystems. Many contemporary OSs even choose to ignore the sticky bit entirely for executables.

However, once again, many modern OSs add a spin to this flag. Just like with the setgid bit, when applied to a directory, the sticky bit takes on special meaning. In this case, it is sometimes referred to as the "restricted deletion" bit.

As the name implies, when set on a directory, this bit will restrict who is allowed to delete or rename files within that directory. Specifically, only the owning user of the files will be permitted to make such changes.

Lets consider our earlier example again, but this time we will assume that there is a subdirectory in the project directory belonging to a user, Alice. Alice is responsible for the module of the project contained within the subdirectory, and all changes need to go through them, especially if the changes remove files! So, if Alice is having trouble with users deleting files before consulting them, they can set the sticky bit on the module's subdirectory. This will make it so that only they have the power to delete files from the directory. This won't, however, stop users from erasing the contents of a file.

Final Thoughts

There was no specific need for me to get into this right now. I just wanted to finish up the explanation I started in the last post, before I move on to the next thing.

The next post will be back on-topic with this month's project. I just didn't want to leave this out, and needed to pad time while I got some things together.

Now we can get back to our scheduled nonsense.

[frog707]

his father's LinuxSaber

With apologies to George and Marcia Lucas.

[Luke is training with his father’s LinuxSaber ... and a temp file.]

Ben: Remember, Luke: a sysadmin can *feel* the Kernel *flowing* through him.

Luke: You mean, it prompts you for input?

Ben: Partly. But it also obeys your commands.

[Luke attempts to delete the file and a gets a “permission denied” error.]

Han: [amused] Hokey system calls and ancient command shells are no match for Windows Explorer on your desktop, kid.

Luke: You don't believe in the Kernel, do you?

Han: Kid, I've surfed from one end of the Web to the other. I've seen lots of strange stuff, but I've never seen anything to make me believe there's one all-powerful Kernel controlling everything. There are no drivers for *my* HDD. It's all a bunch of registry hacks and nonsense.

Ben: [opens a terminal window] I suggest you try it again, Luke. This time, let go of your mouse and use the keyboard. [He maximizes the window.]

Luke: But with this window maximized, I can't even see the desktop! How am I supposed to delete the file?

Ben: Icons can deceive you. Don't trust them.

[numberonewizardpuppy]

System Admin Undercover

Recently got a new job, have been very intentionally avoiding I.T. Roles while job hunting, and so the computer problems at my new office aren't my problem here, and I plan to keep it that way. Lots of problems internal to the company with IT, I don't have SuperUser Privileges here, so I keep quiet . Their IT Guy is outsourced and seems pretty flaky, weeks at a time to respond to simple tickets. Could I solve everything wrong if I was given Admin? Yes. Am I going to speak up? Hell no! Windows 10 sucked, Windows 11 is worse; I'm just glad to not need to take any work home with me and if my ability to function is stalled because their outsourced IT Guy is a dunce, that's not my problem.

I just find it funny listening to the ongoing problems, because they objectively shouldn't be problems and could be solved in minutes a piece. Kudos to their IT Guy though, man must be living the dream.

Also, Windows 11 is just straight up malware and it's barely veiled these days, I write Linux User-ly

[blackmoreops]

Atop vs Btop vs Htop vs Top: The Ultimate Linux Monitoring Tools Showdown

When it comes to keeping tabs on your Linux system’s performance, choosing the right monitoring tool can make all the difference between efficient troubleshooting and frustrating guesswork. From the classic ‘top’ command to more sophisticated alternatives like Atop, Btop, and Htop, Linux offers a range of options to suit different monitoring needs. System administrators and power users alike…

Atop vs Btop vs Htop vs Top: The Ultimate Linux Monitoring Tools Showdown