Scheduled Maintenance: We are aware of an issue with Google, AOL, and Yahoo services as email providers which are blocking new registrations. We are trying to fix the issue and we have several internal and external support tickets in process to resolve the issue. Please see: viewtopic.php?t=158230

 

 

 

Single User Security

Off-Topic discussions about science, technology, and non Debian specific topics.
Message
Author
millpond
Posts: 698
Joined: 2014-06-25 04:56

Re: Single User Security

#21 Post by millpond »

https://www.debian.org/doc/manuals/secu ... ian-howto/
-----------------------------

This goes a long way for what I am looking for.
Bookmarked.

When I work on a project I always keep security issues as the last concern, so as to be able to avoid permissions problems while developing. Afterwards I can do as needed.
For example while working on websites I often use Win XAMPP, and then move to Linux and work out the permissions issues there.

CwF
Global Moderator
Global Moderator
Posts: 2625
Joined: 2018-06-20 15:16
Location: Colorado
Has thanked: 41 times
Been thanked: 190 times

Re: Single User Security

#22 Post by CwF »

...well, maybe if you had read my post..
and pkexec is polkit.

User avatar
bw123
Posts: 4015
Joined: 2011-05-09 06:02
Has thanked: 1 time
Been thanked: 28 times

Re: Single User Security

#23 Post by bw123 »

millpond wrote:
...The issue at hand is what are the potential problems with running as superuser on a system specifically designed to run at minimum security levels. Ans what are best pracices for THIS mode.
...
That's easy, don't do it. It's not a MODE, it's like swimming with sharks. yeah you can like put a bandaid on the cut and smoke something to stay calm, but the damn sharks are unpredictable. Blood in the water ring any bells? Have you ever wondered why Malware and Virus scanners are millions of dollar bidnezzes on wndows machines?

Airgap the machine, and make a lot of backups. I'm sure the wife can stay off facebook while running as root?

edit: I thought at first you were another user that had a similar username. This person was very sensible and contributed a lot to the forum, but sadly I forget the correct name. It was something similar to millpond, and I took your post seriously for this reason. Now, after reading several of your posts, I don't.
resigned by AI ChatGPT

Bulkley
Posts: 6382
Joined: 2006-02-11 18:35
Has thanked: 2 times
Been thanked: 39 times

Re: Single User Security

#24 Post by Bulkley »

bw123 wrote:That's easy, don't do it.
Agreed.

What the OP is trying so hard to do is way too complicated and just going to cause endless trouble.

Possible alternatives:
Kiosk OS - runs in memory; reboot starts fresh.
Live-USB with persistence - I suggest MX Linux which is full featured and easy to set up persistence.
Multiseat configuration - one computer serving two or more terminals.

User avatar
dilberts_left_nut
Administrator
Administrator
Posts: 5343
Joined: 2009-10-05 07:54
Location: enzed
Has thanked: 12 times
Been thanked: 66 times

Re: Single User Security

#25 Post by dilberts_left_nut »

Or just learn how permissions work.
AdrianTM wrote:There's no hacker in my grandma...

millpond
Posts: 698
Joined: 2014-06-25 04:56

Re: Single User Security

#26 Post by millpond »

CwF wrote:...well, maybe if you had read my post..
and pkexec is polkit.
Hmmm... pk... Polkit.

I did read your post. Very good points.

My scripts do not use sudo. I first started using Linux beore Debian even existed so regard much of the newer stuff as an imposition. I can, and have run those scripts out of rooted terminals, but am simply inquiring as to whether anyone has taken the opposite approach and have the superuser using 'using user level terminals' to run anything suspect. Like ssh. And browsers. So far the only real option appears to be a VM, or a VT for non-gui stuff.

millpond
Posts: 698
Joined: 2014-06-25 04:56

Re: Single User Security

#27 Post by millpond »

Bulkley wrote:
bw123 wrote:That's easy, don't do it.
Agreed.

What the OP is trying so hard to do is way too complicated and just going to cause endless trouble.

Possible alternatives:
Kiosk OS - runs in memory; reboot starts fresh.
Live-USB with persistence - I suggest MX Linux which is full featured and easy to set up persistence.
Multiseat configuration - one computer serving two or more terminals.
OK.

Multiseat.

Can this currently be done with TWO users using X?

millpond
Posts: 698
Joined: 2014-06-25 04:56

Re: Single User Security

#28 Post by millpond »

Bulkley wrote:
bw123 wrote:That's easy, don't do it.
Agreed.

What the OP is trying so hard to do is way too complicated and just going to cause endless trouble.

Possible alternatives:
Kiosk OS - runs in memory; reboot starts fresh.
Live-USB with persistence - I suggest MX Linux which is full featured and easy to set up persistence.
Multiseat configuration - one computer serving two or more terminals.
I know how they work, but find it incredibly annoying spending countless hours troubleshooting scripts only to find its an obscure permission problem. I prefer getting things working as superuser, and THEN running it at user level. After 25 years, whatever 'risks' involved appear to be minimal.

I have used this approach on my heavily modded ecommerce website, without any issues. Permissions have been set, and set correctly.
For about 8 years now.

xepan
Posts: 89
Joined: 2018-11-28 06:38

Re: Single User Security

#29 Post by xepan »

millpond wrote:much of the newer stuff as an imposition. I can, and have run those scripts out of rooted terminals, but am simply inquiring as to whether anyone has taken the opposite approach and have the superuser using 'using user level terminals' to run anything suspect. Like ssh.
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.
Last edited by xepan on 2019-01-19 17:14, edited 1 time in total.

CwF
Global Moderator
Global Moderator
Posts: 2625
Joined: 2018-06-20 15:16
Location: Colorado
Has thanked: 41 times
Been thanked: 190 times

Re: Single User Security

#30 Post by CwF »

@xepan, you could maybe edit that, I don't think CwF said that...
..and I believe 'user' and 'root' are common terms, as is "terminal'. *-emulator is not more specific or critically clarifying.

@millpond; I'm not sure what I missed in my first response other than 'groups' maybe. The solution to whatever issue you have yet to declare is likely solved with a specific sudoers.d declaration which means you type 'sudo' if ran as user. Typing 'pkexec' with a corresponding polkit declaration in /usr/share/polkit-1/actions is likely not applicable, maybe... If your process would benefit from terminal feedback, then the terminal could be called up with pkexec. Otherwise use sudo.

Also missed in that first response:
CwF wrote: I assume you have already purged any gksu use.
So your response that gksu is missing means I'm wasting time here.

xepan
Posts: 89
Joined: 2018-11-28 06:38

Re: Single User Security

#31 Post by xepan »

@CwF: sorry. i changed it.

User avatar
llivv
Posts: 5340
Joined: 2007-02-14 18:10
Location: cold storage

Re: Single User Security

#32 Post by 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
In memory of Ian Ashley Murdock (1973 - 2015) founder of the Debian project.

CwF
Global Moderator
Global Moderator
Posts: 2625
Joined: 2018-06-20 15:16
Location: Colorado
Has thanked: 41 times
Been thanked: 190 times

Re: Single User Security

#33 Post by 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.

User avatar
Head_on_a_Stick
Posts: 14114
Joined: 2014-06-01 17:46
Location: London, England
Has thanked: 81 times
Been thanked: 132 times

Re: Single User Security

#34 Post by Head_on_a_Stick »

millpond wrote: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
deadbang

xepan
Posts: 89
Joined: 2018-11-28 06:38

Re: Single User Security

#35 Post by xepan »

CwF wrote: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.

User avatar
Head_on_a_Stick
Posts: 14114
Joined: 2014-06-01 17:46
Location: London, England
Has thanked: 81 times
Been thanked: 132 times

Re: Single User Security

#36 Post by 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?
deadbang

ruffwoof
Posts: 298
Joined: 2016-08-20 21:00

Re: Single User Security

#37 Post by 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 Image

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
Global Moderator
Global Moderator
Posts: 2625
Joined: 2018-06-20 15:16
Location: Colorado
Has thanked: 41 times
Been thanked: 190 times

Re: Single User Security

#38 Post by 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
Posts: 89
Joined: 2018-11-28 06:38

Re: Single User Security

#39 Post by 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).

User avatar
Head_on_a_Stick
Posts: 14114
Joined: 2014-06-01 17:46
Location: London, England
Has thanked: 81 times
Been thanked: 132 times

Re: Single User Security

#40 Post by Head_on_a_Stick »

CwF wrote:complicated the question
^ This :twisted:
xepan wrote: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...
xepan wrote: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).
deadbang

Post Reply