Linux Privilege More Than Just Root & Unprivileged

An important concept to understand on Linux is account privilege but there's a lot more to it than just your unprivileged user account and the super user root account there is a lot more nuiance.

==========Support The Channel==========

=========Video Platforms==========

==========Social Media==========

==========Credits==========
🎨 Channel Art:
Profile Picture:

#Linux #OpenSource #Root #FOSS #LinuxDesktop

🎵 Ending music
Track: Debris & Jonth - Game Time [NCS Release]
Music provided by NoCopyrightSounds.

DISCLOSURE: Wherever possible I use referral links, which means if you click one of the links in this video or description and make a purchase I may receive a small commission or other compensation.

[mikonunyez]

"Security is hard". As a cybersecurity professional, I approve this message.

[GSBarlev]

This is a great explainer. You can really tell that POSIX' privilege model comes from the mainframe space where you had a ton of users with varying degrees of ownership / trustworthiness all sharing one giant machine of vacuum tubes and mechanisms that went "bing." I kinda like that it's taking this new form of properly keeping daemons on short leashes.

[tablettablete]

What about the other security tools?

- LSM
- SELinux
- AppArmor
- Landlock

- SECCOMP
- No new privs
- Secure Bits
- Capabilities

[aDifferentJT]

I feel like the terms privileged and unprivileged are most useful nowadays when talking about exploits, where you talk about escalating from an account lacking a particular privilege (an unprivileged account) to one with that privilege (a privileged account), but those terms have escaped that context and are now used in other contexts, where they are less relevant.

[CMDRSweeper]

Yes, this is a concept that you quickly learn to grasp if you are a home server operator.
And that is when you learn that the simple POSIX group model, even if it conflicts with the Windows method of doing things, is surprisingly brilliant.

[FengLengshun]

Yeah, I became really aware of this... after I locked myself out of my homedir after messing around with SELinux. As well as playing around with Docker on my other device which takes care of running my web services and only have access to what I mount to the service. It's an interesting way to limit access, though sometimes frustratingly complicated as well.

[stevenclark]

Beyond root there is kernelspace. Many kinds of security flaw require some path into the kernel, like BPF or a driver, to manipulate them. Also It's possible to construct a system using some kinds of mandatory access control where even root is limited once the system is turned on.

[MechMK]

It's very important to note that "nologin" does not mean you can't get a shell as that user. You can do so through sudo -su <user>. Also, I would not say a system account like all the systemd stuff is "unprivileged", just because you can't log in as that user. Because you can absolutely gain access to a process that runs as that user and get that process to perform actions, like, say, delete a file.

[Wulfsbane]

I used term super user for root user. I used system account for service like web server. I used admin account that is user account that can use sudo. I used term user account for normal users and guess account. I been unix and Linux system admin for over 30 years

Most people were lucky enough to not be using Fedora when they switched SELinux to enforcing by default and basically no packages had policies included. That was a nightmare 😂

[capability-snob]

It's one of the most common mistakes in understanding security: it's not more or less privilege, usually, it's privilege to do and access different things.

[fcolecumberri]

There is even more nuance, different users might be members of different groups. There are files (and devices in disguise as files inside /dev/) that can only be accessed by certain groups, therefore you know that a www-data won't be able to access your webcam because /dev/video0 is own by the video group and www-data is not a member of that group while you can. with that you know that even if an account got compromised (let's say a bad code injection on the web backend run by www-data) the possible damage is more less contained to only what www-data could do.

[JamesTK]

I give Brodie permission to backdoor my system. Oh wait, he's probably already done so before I finished watching this video... Who needs privilege once you have physical access.

[cameronmanicone]

Just wanna say i love that all these new people are learning about linux but just remember, linux is not windows.

Have fun in the open source world everyone:)
I highly recommend switching to a distro that you like on your laptop and or desktop.
Lastly remember to support the Devs. If you like a project consider donating. Or helping develop.
If someone gives you someone that you value, maybe consider giving them something of value.

[Qyngali]

I call the mixed privilege accounts specific privilege accounts, or single task privilege accounts. This probably just my personal invention though. 😅
Meaning, an account that only has the rights to perform a single or a set of functions.

[scottfranco]

The problem in Unix/Linux is that, for a host of reasons, users are encouraged to take root permissions. Sudo is used way to often. This breaks down into two basic issues. First, users are encouraged to install programs with privileged files or files in privileged areas. Second, in order to fix up problems, it is often necessary to modify system privileged files. The first issue is made far worse by effectively giving programs that are installing themselves global privilege to access system files and areas. Its worse because the user often does not even know what areas or files the program is installing itself in.

The first issue is simple to solve: install everything a user installs local to that user. Ie., in their home directory or a branch thereof. The common excuses for not doing this is that "it costs money to store that, and users can share", or "all users can use that configuration". First, the vast majority of Unix/Linux system installations these days are single user. Second, even a high end 1tb M2 SSD cost 4 cents per gigabyte, so its safe to say that most apps won't break the bank. This also goes to design: a file system can easily be designed to detect and keep track of duplicated sectors on storage.

The second issue is solved by making config files or script files that affect users local, or having an option to be local, to that particular user. For example, themes on GTK don't need to be system wide. They can be global to start but overriden locally, etc. A user only views one desktop at a time. The configuration of that desktop does not need to be system wide.

My ultimate idea for this, sorta like containers, is to give each user a "virtual file system", that is, go ahead and give each user a full standard file tree, from root down, for Unix/Linux, BUT MAKE IT A VIRTUAL COPY FOR THAT USER. Ie, let the user scribble on it, delete files, etc., generally modify it, but only their local copy of it. The kernel can keep track of what files are locally modified by that user account, akin to copy on write paging. You can even simulate sudo privileging so that the system behaves just like straight Unix/Linux, but only modifies local copies, etc.

[ahumeniy]

In Soviet Russia, there are no privileged accounts.

[vilijanac]

The most confusion I had, was that also file permissions take into play. You want to have access to run a system account service under another user.
If you as root give the system account privileges to a user, the user overwriting the file with, if is having write permissions, can't restart the service no more.
It all depends on the service actually, so even restarting the server might not bring the service up. As it is hitting a file (using), that has new user settings.
That is good.

[the-digital-idiot]

It's like the laws of relativity, the root user is like the speed of light, the fastest thing in all reference, the most privileged user, but everything else is relative. You can only tell if a user is privileged by comparing it to a different user, just like how speed is also relative.

[guss]

The term "least privileged account" - in system security speak - doesn't mean "a specific account that has less privileges", it means "give each account the minimal set of privileges they need to be effective". The root account is also a "least privileges account" - it has just the privileges that it needs, i.e. - all of them.

The UNIX privileges system isn't fine grained - generally privileges are about what files you can access (often due to your group membership, which is treated something like "roles" would be in a fine grained permissions system) - you can access the ttyS0 device file if you are a member of the "dialout" group, with the one exception being the UID 0 account (often called "root") that the kernel and a lot of system applications just check for EUID 0 (not a typo). All of the "not exactly user accounts" talked about in this video are of the "members of groups that grant limited access to the file system" - which works in UNIX because of the idea that everything you do in UNIX are processes (owned by users who are members of one or more groups) accessing files.

The problem is that this UNIX setup just isn't working for a modern operating system facing modern threats - file based access lists aren't good enough (even with more fine grained security than just "group membership", that you get with modern file system ACLs): there are tons of system calls, network access, automatically created files and directories, etc. To solve this, Linux developers have added two very important systems: capabilities and mandatory access control - which I thought this video was going to be about these. Capabilities allow a an account to gain a specific capability that was reserved for UID 0 - such as listening to ports less than 1024, or creating mounts - or for a UID 0 process to drop capabilities that it doesn't need (under the "least privileges" principle - you can be "root" with less privileges); Mandatory Access Controls (SELinux, AppArmor, SecComp) allow the system to attach "behavior boundaries" to files and system calls and prevent access from processes that would be able to access them under normal UNIX rules. For example: under UNIX rules, Apache CGI module can execute any executable it knows the path to - which can be a problem (Apache has its own limits on what it allows, but those are not hard to circumvent), but with SELinux the kernel will block it from running executables that aren't specifically tagged with the "httpd_sys_script_exec_t" tag - even if Apache was running as root.