I've read much about the issues with logging in as root. While I agree that being root in any GUI does open some vulnerabilities I also believe there must be a safe way to use it. What if I login "normal" to whatever GUI I'm using and as root on let's say tty1 to do all my monitoring/updating/configuring etc?

That is one way to do it. In any case, do NOT leave the Root account open for longer than needed....okay, maybe you're the only one leaving finger prints on the keyboard, but still...
And yes, Root does not get a GUI (in the distros I remember, the older CentOS did, that was bad...)
But, your general drift is correct....
Melissa

I have been known to do similar -- there's nothing unsafe or wrong about logging into a terminal as root and, as long as you're the only one with physical access, staying logged in as long as you like. I can't recall though whether having root logged in on a TTY stops the user who is logged into the GUI from shutting the machine down or not the way it does when a root terminal is opened within X11 -- that's more of a usability thing than security though.

There are a million ways to skin a cat. You need to do a risk/reward analysis + security audit and decide what you can live with.

Root is a tool and has its uses like any other tool. It's not a poisonous snake that's going to bite you. But, if not safeguarded properly it can be turned back on you and used to hurt you.

I'm a sec nut. I'm ultra paranoid. I run an SMB network at home w/ a gateway, NIDS, HIDS, a domain controller, segregated wifi / LAN on different subnets, a DMZ and an intelligent, adaptive UTM+DHCP+DNS+FW appliance that I built myself at the head of my LAN.

Spread over the entire net, between real and virtual, I have more than 20 "things". I don't want to have to have a monitor and keyboard for all of them. I don't want to have to go to each one to play with it. I want to sit on my fat butt in my easy chair and admin it all from my main console.

I like ssh. I like the .deb branch. All of my internal systems have sudo with ssh root login disabled, root account disabled and allow/deny configured. I log in and elevate when I need to.

Some projects can get complex. I'm building an OpenVPN server on an rPi in my DMZ. I usually have 4 terminals open to do it:

1) Root GUI
2) User GUI
3) Root CLI
4) User CLI

I just find it easier to click around to what I need instead of having to constantly change directories and permission levels.

Now my gateway on the other hand is my outermost physical boundary and faces the outside world. I have it set up so that ssh is completely disabled until I need it. Then I have to log in to the web interface, which can only be done locally by wire as user, enable ssh and then login to it. The main reason for that is that I didn't build the OS that runs the gateway and to make everything jive the devs set it up so that ssh auto-logsin to root b/c everything that has to be done in the CLI has to be done from root. I'm just not comfortable exposing that to the outside world. I don't want anybody to even be able to knock that port.

It's your thang. Do what you want to do. I can't tell ya who to sock it to. But I would highly advise against a scenario where something is set up as root, CLI or otherwise, and exposed to the outside world w/ zero sec config.

Say what...?

The root user is a fundamental concept of Unix and Unix-like OSs such as GNU/Linux.

The common advice to avoid becoming root is repeated parrot-like by those who do not know what the purpose of the root user is! They intend to remain ignorant of it and want to assure that everyone else remains similarly ignorant.

Root is not a hazard, or a plague to be avoided, or a bad thing in any way. It IS a powerful and fundamental system concept that you must learn about however .

Learn about it, and the concepts of Unix ownerships and permissions, and use it in the way it is intended to be used - life will be good!

Use it without knowledge, or abuse it and you will likely have trouble as a result. The same can be said about [ENTER RANDOM TOPIC HERE], so this should be nothing new to most humans.

As per the example in the original post, it is the permission in the current scope that is important. If the GUI is opened as a normal user then it, and its children have that normal user's permissions. If the tty is opened as root (or if you su to root within it), then that tty and it's children have root permissions beyond that point. The root environment of the tty has no connection to the normal user environment of the GUI in this scenario, as you correctly suppose.

I think a lot of people familiar with other alleged OSs think that if "they", the human user, becomes "administrator" then all of their other activities take on that power too, and this is not true within the sane Unix-like environment.

2 members found this post helpful.

Um, yeah, that's pretty much what I just said: Don't throw it out there for just anybody to use, here are some of the ways I use it and secure it so that it's a useful tool and can be used constructively by me and not used by others to harm my systems.

root CAN BE a hazard, as protections that a user gets don't apply to root.

Even for the experienced root user, simple typographic errors can wipe out the system, where for a user it simply gets a "permission denied".

The problem with GUI environments is that the GUI was designed to work in a USER environment - and when it isn't there can do unforseen things you DON'T want, as you didn't create the functions used in the GUI. Since you don't know all the functions... you don't know what would happen when those functions get used.

Which of course, is one of the million reasons to back up not only your data but your installation and configuration as well.

I personally feel I have a lot more room to play, learn, tinker, build and explore if the only consequence to blowing things up is having to spend an afternoon reloading my install / config and data.

i think you're pretty much spot on with this.

also see:
https://en.wikipedia.org/wiki/Princi...east_privilege

@ astrogeek - one up
Melissa

That is all fine on a test machine.

But you do that on a production server, and it can get you fired.

1 members found this post helpful.

Do that on a production server and you will get fired.

It may not be "spend an afternoon reloading". I have seen "reloading" take days from backup.

Damaging a 50TB production filesystem is NOT something you want to do. Recovery can take several weeks.

You can "play, learn, tinker, build and explore" on a small standalone system with only one user. No problem there (depending on the organizations security requirements, you might have to disconnect the network).

But doing that to a production server... no. You don't take chances there.

2 members found this post helpful.

I said *personally*, as in my personal stuff. I don't have anything on my network with drives big enough that it takes more than an afternoon to reload.

And of course you don't take chances like that at work. The sad part is that that even needs to be said. But, with some of the boneheaded repair requests I've got after somebody with 17 degrees behind their name decided to pull some ID10T crap; unfortunately it needs to be said.

Just remember:

• It is always possible to find a way to ask a computer to do anything, even to destroy itself.
• A digital computer excels at saying, "No."
• A digital computer sucks at saying, "Yes."

When you are logged-in as root, the answer to every request is: "Yes, master." If instructed to shoot itself in the foot, it will take careful aim. It doesn't know any better. It doesn't "know" anything!

This is why you want to studiously practice "the principle of least privilege." By setting the boundary-fences around yourself as close as possible, and by assuming multiple user identities according to whatever you are doing at the time, you maximize the computer's ability to "just say No."

The simpler the login the fewer bugs are encountered.
In root context many bugs become security risks.
As root run a light bug-free GUI desktop, and you are save. But do not start heavy buggy applications like Firefox!