Single User Security

[xepan]

@CwF: sorry. i changed it.

[llivv]

I'm still interested in understanding how millpond is setting his things up. Yes No I don't understand what a rooted terminal is, but if millpond has been using linux for 25 to 30 years I'm more interested in how things were done in linux before my time.
It's kind of like the communication gap between younger and older generations. And it's not funny how that communication gap very rarely get bridged.
So I'm doing my best to be patient with the newfangled (in comparison) best practices I've developed over time and not let them interfere with others developing their own methods. Try to give pointer when I can and learn as much as possible from others too. It is the Linux/Gnu/Debian way to let anyone that wants to hacker on the software.
I've already figured out that millponds eccentric (off centered, [1] if you will) methods are not mainstream and I'm waiting for that light to go on when I actually figure out how the setup works.
I was just thinking about the rooted terminal and wondering if it's like uml which many here have surely heard of?
Or perhaps running xserver using xsm which I haven't done for a long time.
Does that make sense?

[1] DogFishHead Brewery "for the slightly off-centered" Cheers

[CwF]

You're exactly right llivv. The term 'rooted' is a misappropriated term from smart phone lingo. When a factory device or computer without any 'factory' root account is then subjected to 'rooting' software to gain access, then the device is "rooted". I think the correct term here is simply a root user terminal. In this case formerly provided by gksu for a user, or the default while loogen on as root.
So first, figure out the newer polkit policy and add a policy file for the preferred terminal-emulator. Where that isn't applicable, do the sudoer.d thing, and there you go.

My two cents is on the fact that there are a hundred gksu references on the system(s). To avoid that, maybe everything is happening in gksu provided terminals, which is now broken. So the temptation is to simply run as root.

Since gksu is absent from buster there are a handful of things that need a choice. You could simply leave the stretch versions in place. Or you can check sid for policy kit versions. Once everything has an authority reference of some kind other than gksu, then purge it and move on...

Or, I'm way off and there are other issues!?

Of note, all my images have a fully graphical desktop for the root user and it's set up for what root might do. Which it never does, since I never need it...since I have users and they work too, so...ya.

[Head_on_a_Stick]

So far the only real option appears to be a VM, or a VT for non-gui stuff.

How about systemd-nspawn?

Adopt, adapt & improve: http://forums.debian.net/viewtopic.php?f=16&t=129390

[xepan]

Yo.

My two cents is on the fact that there are a hundred gksu references on the system(s). To avoid that, maybe everything is happening in gksu provided terminals, which is now broken. So the temptation is to simply run as root.

Perhaps you can give me an example for one of those references, i am still pretty confused.
I haven't got gksu installed (neither polkit, btw), and on voidlinux i don't even find pkexec (which confuses me even more). But as of now i didn't run in any problems. (described above as restrictions). I also don't remind any problems with the other distros and OS'es i tried including Debian.
I never really set up anything to gain such.

thanks in advance.

[Head_on_a_Stick]

Here's how I overcome "restrictions" on my system: we start with a normal user in the sudo group, with sudo installed and root account disabled (ie, with no password set at all).

First, add the wheel group to the system:

Code: Select all

# groupadd wheel

Then edit the file at /etc/pam.d/su and un-comment these two lines:

Code: Select all

auth       required   pam_wheel.so group=wheel
auth       sufficient pam_wheel.so trust

The first line has had "group=wheel" added to the end so that only members of the wheel group can use `su` (just like in the BSDs), the second line allows members of the wheel group to `su` without a password.

And finally we remove the sudo package:

Code: Select all

SUDO_FORCE_REMOVE=yes aptitude purge sudo

The root account is now locked, sudo doesn't exist and only my user can attain elevated permissions (without needing to enter a password):

Code: Select all

empty@shinken:~ $ su -
root@shinken:~ #

^ That's a root terminal folks, what the **** are you using `gksu` for?

[ruffwoof]

The main appeal of OpenBSD and a reason for why I moved over to that from Debian is that X runs as user and you can set all setuid's off for 'others', not have the X user in group wheel, no su/sudo etc. and in effect have it contained. Run all root commands from a tty/console.

If it really really is necessary to run a root/X program, then you can xhost + in the user X window and fire up a foo.bar gui root program from the tty using something like

DISPLAY=:0 foo.bar

Just make sure no internet activities are also running at the same time. For my purposes I have no such need for any root X programs, and to simplify running root commands from cli I use tmux and a tput menu system

For online security I just regularly ctrl-shift-del ... and clear out the cache (store all bookmarks in a local html file) ... so low risk of cross site loss of userid/passwords.

[CwF]

@xepan
Maybe h.o.a.s clarified or complicated the question I don't know. I mentioned groups earlier, and did not mention 'rootless' distros. So I don't know the correct path for the OP.

Bottom line is 'Linux' provides multiple paths to the same conclusion with pro/con beyond my concern. The 'wheel' group method as outlined is one such path I believe originated outside of debian. The installers of various distros vary in this regard by either assuming a root account will exist and setting it up in the install sequence, OR the installer is 'rootless' and steps through setting up only 'users', with the alternative 'wheel' group. A great example of reinventing the wheel, and calling it so!

Whenever gksu came about I don't know, but it is another reinvented wheel and basically a crutch. I guess the primary purpose was to provide a user dialog to enter a password to register authority in a system that did not have any other way set up. A similar functionality could be done with sudo, using declarations concerning the user rights, or using alternatives like yad or zenity within scripts to acquire a user password in gui's.

Distro's with a root account still exist, yes? The debian installer I used was the 'jessie' generation, and an i386 'stretch'. Those installers set up a root account first, then users. So those are 'root account' installs. I have not modified that nor do I feel the need, and I mentioned all 4 of my installs have full gui root accounts...that I no longer user. How a current 'buster' installer treats this subject I don't know. The theory is a 'rootless' install may be more secure since breaking in to the root account yields no cake.

I roll my own installations and the 4 I have are 8.1, 8.5, 8.8, and a 9.1. They are now about 8.8, 9.5, 10.x, and 10.x. I don't nuke and pave, I don't reinstall. I'm am no wide ranging expert and have a narrow goal and experience with 'Linux' since I choose and focus on debian. So, if the installer creates a root account, that's my answer. Sudo is a currently maintained old school package still in all flavors of debian. Polkit is rapidly evolving and current in debian. I recently took my 2 images as mentioned to 'buster' and ran across the gksu issue, the root path errors, and incomplete polkit implementations. Examples like a root terminal, gdebi, synaptic, gparted, bleachbit (from sid), etc. all show the change to polkit from prior methods. I presume the OP is finding these same issues, and they are fresh in my memory.

Back to the OP issues, my impression is commands issued from a 'user' are stepping outside user directories into root created files or directories and the command fails. Issued from a root terminal, or a gksu root terminal (see hoas's terminal example) then the command succeeds. It is possible for a command to be within user rights while the file(s) called on within the command are not within user rights. Just a guess...

Personally I'd prefer not to complicate debian with 'arch' or 'bsd' methods until debian says to do so. I mentioned I'm narrow. So anyone please chime in and feel free to add to my generalizations, or offer additions and corrections.

[xepan]

Thanks for sure.
Thing is: i still don't understand what the trouble is
As said above, i don't set up anything. I just type su, and that's it.
If i want to start a gui app, i just type it's command in a terminal , after i typed su (load of yada you have to use su - and such, but most of the time i simply forget it)
I gave up on displaymanagers quite some years ago, and there i used gksu to start a gui app (there was no pkexec back then).
Going back and forth my result was that HeadOnASticks "solution" (to a problem i still don't understand) is that he doesn't have to type a password (?).
Prettty much the only application i need to run as root is gparted anyway.

I don't really do much with the PC. There might be cases for the mentioned problems or restrictions, but i don't know them, as i don't do enough. In this thread i sure haven't found an example for such yet.

sidenote: Yes, debian still sets up a root account per default, you can set up sudo during installation though (and then don't have a root account, duh. Been like that for a while now, but nothing changed in Stretch).

[Head_on_a_Stick]

complicated the question

^ This

HeadOnASticks "solution" (to a problem i still don't understand) is that he doesn't have to type a password

Yeah, pretty much, along with forbidding `su` access to users not in the wheel group, which I think is a great idea.

AFAICT that is what the OP wants but I am also having trouble understanding the "problem" so I've probably just added a load of noise...

debian still sets up a root account per default

Not quite — the installer asks for a root password and if none is provided then the root account is locked and the first user is added to the sudo group, just like in Ubuntu (and BunsenLabs).

[CwF]

... is that he doesn't have to type a password (?).
Prettty much the only application i need to run as root is gparted anyway.

See my first response for no passwords. See if you have a /etc/sudoers.d/ file. For gparted there is now a policy file for /usr/share/polkit-1/actions. With polkit installed, modify the org.gnome.gparted file with <allow_active>yes</allow_active>,

[millpond]

What are root and user terminals?
terminal-emulators? probably.
But what the heck is a user terminal and a root terminal?

I sure can run ssh as web-browsers as root.
You might want to give a real and detailed example what you are speaking of.[/quote]

Xterms and VTs(ctrl-altxxx). However VTs cannot run GUI apps.
In this case either - depending who is logged into the terminal.

As an exampke: I use personalized directories for my files. In running my P2p client and FF (as a user) I kept running into permission problems which persisted with su, but went away booting to superuser. there is alot of stuff I could have done to fix the issue for the user account, but wanted to spend that time loading the system and then dealing with permissions issues *last*.

And then the thought occurred that some of these permisisons issues were *new* and not 'traditional' - which made me think that if this was destined to be a hacked SID system: In for a penny, in for a pound.

[llivv]

I never thought of this thread as a post asking for a solution to a specific issue, but rather as a discussion thread to probe for ideas on different ways to secure a box and also learn more about the ways Debian is changing currently.

@millpond:

There are at least 4 other threads in the forum with the same su issue.
New convention based on upstream is now being used for su

Code: Select all

su -

I noticed the issue in Sid approximately September 2018 and posted about it here in
Debian Development Section

CwF mentions it as well above http://forums.debian.net/viewtopic.php? ... 30#p689944
Job posted about the same issue and it's also mentioned in two other posts I know of here at FDN.

su man page is one of the manuals I keep a close eye on, it's changed several times making for some unusual advice/depreciation statements in stable testing and sid.

With all these "Path problems" and "Directory merge and link" issues rearing their ugly hacks, changing policy, initializing CoC's everywhere, and implementing new tools that obfuscate the changes made, even pottering can't find simple commits in systemd.

I see huge changes being made with little to no regard to backward compatibility.

Some devs like that. ( I know Kibi for one was excited to get out of XstrikeForce.
Probably close to 10 years ago and probably due to the excessive bug reports being submitted
showing user error - even from other devs.) I also remember him praising the inclusion of wayland as a way to finally get rid of xserver...

It was really a sad sad thing to watch devs file bug reports on wildly customized xservers without even testing the default xserver first..... I can only imagine what it would be like to have to address that kind of thing with only a 3 of 4 maintainers handling the load....

Other Devs seem to agree that so much change in the base system is not being handled in a way that is beneficial to the project.

I admit some of the fussy (probably more than the project wants to admit publicly) is that the paid Devs have to feed their families, etc etc.....A lot of the paid devs are working (for companies that have little or no interest in software freedom other than there being a cheap way to get free system support from unpaid devs doing gratis work). Also utilizing unscrupulous tactics to cover their tracks and keep the general public uninformed.. I doubt I have to name names here but a few of the historical abusers come to mind.

Kinda reminds me of the link H_o_a_S posted in another thread to the july 2018 systemd hug report concerning the loading of the autofs4 kernel module....Which it turns out systemd implemented a long time ago into the systemd early boot code.
Than pottering complaining it was a kernel issue and finally Linus had to find the systemd commit and explain it to pottering.. Linux than revirted the autofs4 module rename in the kernel commit due to pottering not even knowing what the problem is, still doesn't know it...even after Linux explained it to him.
You would think pottering would have a clue what autofs is, at the very least. Maybe than they could find their issue themselves instead of making Linus do the debugging of systemd for them.
And that kind of ineptitude from the systemd project has been directed at the kernel for many years.

I noticed it first during wheezy freeze when I was reporting an issue to DRM/DRI regarding xserver on old intel 830 chipset not being able to start Gnome or KDE with only 8 Mb of ram available for the on motherboard graphics chip.
Systemd was complaining again about how the kernel was at fault for some reason and breaking userspace ie: systemd.
One of the kernel devs in that report (very similar in structure to the one mentioned above) asked the systemd devs what their debug level was. Their reply was debug. (default).
Probably due to them not using or understanding how to use any debug mechanism at the time...Latest rant by pottering makes me wonder if they still don't have a decent systemd debug strategy in place.
It was clear to me that pottering wasn't going to dig though the systemd code himself to find an issue that he thought he could blame on the kernel breaking userspace again...
Just the tip of the iceberg, from what I'm hearing on the wire. .


.

[xepan]

... is that he doesn't have to type a password (?).
Prettty much the only application i need to run as root is gparted anyway.

See my first response for no passwords. See if you have a /etc/sudoers.d/ file. For gparted there is now a policy file for /usr/share/polkit-1/actions. With polkit installed, modify the org.gnome.gparted file with <allow_active>yes</allow_active>,

As of now i just left all systems as they were and it works like a charme.

[xepan]

As an exampke: I use personalized directories for my files. In running my P2p client and FF (as a user)

What are personalized directories?

I know in advance that the next comment will again make use of terms no one has heard of yet.
I am out.

[dilberts_left_nut]

1337 for dirs with the wrong permissions ...

[bw123]

1337 for dirs with the wrong permissions ...

I ran windows that way for yrs. When I tried it on linux, I found out that it's just too easy to delete/edit/create something somewhere that hoses some part of the system, without realizing it, sometimes days or even weeks later. Mysteriously, the system just starts to degrade, and you really don't understand what error you made and where the problem is. Group ownership in particular seems to be somewhat important, in ways that can be hard to understand.

The problem with the strategy of setting everything up to run as root, and implementing user permissions later, is like driving all nails with the biggest sledgehammer you have. The nails are hard to remove later. You don't drive a nail unless you're sure.

[millpond]

HeadOnASticks "solution" (to a problem i still don't understand) is that he doesn't have to type a password

Yeah, pretty much, along with forbidding `su` access to users not in the wheel group, which I think is a great idea.

Unfortunately, in SID, at least for this system: There is no wheel group in /etc/group

[millpond]

1337 for dirs with the wrong permissions ...

I ran windows that way for yrs. When I tried it on linux, I found out that it's just too easy to delete/edit/create something somewhere that hoses some part of the system, without realizing it, sometimes days or even weeks later. Mysteriously, the system just starts to degrade, and you really don't understand what error you made and where the problem is. Group ownership in particular seems to be somewhat important, in ways that can be hard to understand.

The problem with the strategy of setting everything up to run as root, and implementing user permissions later, is like driving all nails with the biggest sledgehammer you have. The nails are hard to remove later. You don't drive a nail unless you're sure.

Good points, and my apparent surprise here is that there has been no FAQs around as to how to restore a system, that has been say, backed up to an NTFS system. A script to restore default permissions and groups. I remember a decade ago on Jaunty something like that happened, and I had to install it on a second drive and note the permissions in /etc/ and i believe, /usr/lib.

In order to gain total control over a system we needs must *understand* it, Not 'obey' it.
I am not persuing NO security. I am trying to make security issues at my own discretion. Isnt this one of the Four Freedoms?
Perhaps its changed in Lennux.


For example, there are plenty of 'hacking' books for taking control over Win systems, and modding them to taste.
Looking for something like that for Linux.

I do like that in Buster the /usr and /lib trees have been simplified. Perhaps that can be expanded to allow for more interaction with other platforms.

[Head_on_a_Stick]

There is no wheel group in /etc/group

Code: Select all

# groupadd wheel