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
Re: Single User Security
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.
-----------------------------
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.
Re: Single User Security
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?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.
...
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
Re: Single User Security
Agreed.bw123 wrote:That's easy, don't do it.
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.
- dilberts_left_nut
- Administrator
- Posts: 5346
- Joined: 2009-10-05 07:54
- Location: enzed
- Has thanked: 12 times
- Been thanked: 66 times
Re: Single User Security
Or just learn how permissions work.
AdrianTM wrote:There's no hacker in my grandma...
Re: Single User Security
Hmmm... pk... Polkit.CwF wrote:...well, maybe if you had read my post..
and pkexec is 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.
Re: Single User Security
OK.Bulkley wrote:Agreed.bw123 wrote:That's easy, don't do it.
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.
Multiseat.
Can this currently be done with TWO users using X?
Re: Single User Security
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.Bulkley wrote:Agreed.bw123 wrote:That's easy, don't do it.
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 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.
Re: Single User Security
What are root and user terminals?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.
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.
-
- Global Moderator
- Posts: 2638
- Joined: 2018-06-20 15:16
- Location: Colorado
- Has thanked: 41 times
- Been thanked: 192 times
Re: Single User Security
@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:
..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:
So your response that gksu is missing means I'm wasting time here.CwF wrote: I assume you have already purged any gksu use.
Re: Single User Security
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
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.
-
- Global Moderator
- Posts: 2638
- Joined: 2018-06-20 15:16
- Location: Colorado
- Has thanked: 41 times
- Been thanked: 192 times
Re: Single User Security
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.
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
- Posts: 14114
- Joined: 2014-06-01 17:46
- Location: London, England
- Has thanked: 81 times
- Been thanked: 132 times
Re: Single User Security
How about systemd-nspawn?millpond wrote:So far the only real option appears to be a VM, or a VT for non-gui stuff.
Adopt, adapt & improve: http://forums.debian.net/viewtopic.php?f=16&t=129390
deadbang
Re: Single User Security
Perhaps you can give me an example for one of those references, i am still pretty confused.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.
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
- Posts: 14114
- Joined: 2014-06-01 17:46
- Location: London, England
- Has thanked: 81 times
- Been thanked: 132 times
Re: Single User Security
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:
Then edit the file at /etc/pam.d/su and un-comment these two lines:
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:
The root account is now locked, sudo doesn't exist and only my user can attain elevated permissions (without needing to enter a password):
^ That's a root terminal folks, what the **** are you using `gksu` for?
First, add the wheel group to the system:
Code: Select all
# groupadd wheel
Code: Select all
auth required pam_wheel.so group=wheel
auth sufficient pam_wheel.so trust
And finally we remove the sudo package:
Code: Select all
SUDO_FORCE_REMOVE=yes aptitude purge sudo
Code: Select all
empty@shinken:~ $ su -
root@shinken:~ #
deadbang
Re: Single User Security
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.
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.
-
- Global Moderator
- Posts: 2638
- Joined: 2018-06-20 15:16
- Location: Colorado
- Has thanked: 41 times
- Been thanked: 192 times
Re: Single User Security
@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.
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.
Re: Single User Security
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).
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
- Posts: 14114
- Joined: 2014-06-01 17:46
- Location: London, England
- Has thanked: 81 times
- Been thanked: 132 times
Re: Single User Security
^ ThisCwF wrote:complicated the question
Yeah, pretty much, along with forbidding `su` access to users not in the wheel group, which I think is a great idea.xepan wrote:HeadOnASticks "solution" (to a problem i still don't understand) is that he doesn't have to type a password
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...
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).xepan wrote:debian still sets up a root account per default
deadbang