Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
Question about permissions to files in a gui
View unanswered posts
View posts from last 24 hours

 
Reply to topic    Gentoo Forums Forum Index Desktop Environments
View previous topic :: View next topic  
Author Message
LIsLinuxIsSogood
Veteran
Veteran


Joined: 13 Feb 2016
Posts: 1090

PostPosted: Sun May 19, 2019 9:34 am    Post subject: Question about permissions to files in a gui Reply with quote

So while this isn't exactly a DE question but it is a question about working in graphical environment, which is basically a must have in any desktop software. I try "really" to abide by the past advice I was provided, which was to basically avoid running graphical applications as root. I think it makes sense to me why, but I will anyway repeat what I had assumed were the problems. First and foremost the idea that with root privileges and application is now capable of doing some many things that could be harmful or undesireable. There I think that says enough, ok.

But here is my problem. In my /etc folder there are plenty of files as well in several other places scattered throughout the filesystem where I would like to open as a regular user without getting access denied errors. Could someone please remind me of the proper procedure for ensuring safety in the way of protecting file system while allowing access either to individual folders for my daily user? Would it make sense to add myself to a new group with slightly elevated permissions and then apply the group permissions to these folders via group ownership? Or would it perhaps be best not to change permissions and work instead with the acl lists that could provide more fine grained control. What are the security risks involved if I choose the wrong one, or the right one even?
Back to top
View user's profile Send private message
NeddySeagoon
Administrator
Administrator


Joined: 05 Jul 2003
Posts: 44959
Location: 56N 3W

PostPosted: Sun May 19, 2019 12:17 pm    Post subject: Reply with quote

LIsLinuxIsSogood,

All files in /etc are writeable only by root. This is deliberate as they control system wide settings.
There are two subsets sets of these file.
Those that are world readable and those that are not.
The split is determined by content. The file that hold secrets, like
Code:
-rw-r-----  1 root  root    1235 May 22  2017  shadow
are only accessible to root and processes that run as root.
shadow holds all your user password hashes. If I can steal that I can run John the Ripper on the content.
That's generally regarded as a very bad thing :)

Going back to the two subsets, many /etc/ world readable files can be overridden by files somewhere in ~/
If you feel the need to edit root readable only files as your normal user, use sudo.
If you want to change the effects of world readable files, look at per user overrides first.
Per user overrides are preferred as etc-update might change the files in /etc and if you miss it, your changes will be lost.

Now decide if you want to make a change that affects all users, or just one. If you are the only user, that may be moot but opt for the easy life, so per user overrides are preferred just to protect yourself from etc-update.

The use of sudo is intended to remind you that you are now root, so don't mess up.
_________________
Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.
Back to top
View user's profile Send private message
Hu
Moderator
Moderator


Joined: 06 Mar 2007
Posts: 14972

PostPosted: Sun May 19, 2019 3:57 pm    Post subject: Reply with quote

Granting your regular user the ability to edit these without going through an elevation process is still bad practice. Depending on the files, that might actually be worse practice than running the graphical editing tool as root. If anything running as you can edit the file, then a rogue process doesn't even need to compromise your root-elevated editor. What are you trying to edit that you need a graphical editor running as root? What is wrong with running your terminal as you, elevating to a root shell within that terminal, and running vim or emacs (the TUI versions) on the file?
Back to top
View user's profile Send private message
LIsLinuxIsSogood
Veteran
Veteran


Joined: 13 Feb 2016
Posts: 1090

PostPosted: Mon May 20, 2019 7:36 am    Post subject: Reply with quote

The issue that Hu mentioned was the idea I was getting at about the risks involved specifically with opening further access to those files from an application...but I'm not sure I understand how this is actually a risk to be honest, e.g. is the threat source from a local application or network? would an existing process that is running on my computer maybe unknowingly be looking for this file, I mean even though it is generally known to be a file in /etc/ that should basically also be known to be owned by root. I mean it would seem like that could present a likely target on the one hand, but on the other hand for what I'm talking about is that something maybe i can go back to the man pages of sudo. And to find out if some other applications may actually have more specific intergration or support for sudo access via the GUI instead of a TUI.

Specifically in the area of text editors, or similar apps like a programmer's IDE or something like that. Basically I would like to be able while working in my desktop session to switch over smoothly and not disrupt my flow of work in the graphical desktop. It would mostly be a luxury as I have no problem accessing it the way of vim, either on the machine or through a ssh connection too.

But I thought it might be more practical (if it does not compromise any security situation) to have my access to certain configurations running in a graphical application. So I've probably in the past done this as root launching the GUI. From the sounds of it that could still be better than doing anything as described above to temporarily lower the permissions or whatever on individual files.
Back to top
View user's profile Send private message
Hu
Moderator
Moderator


Joined: 06 Mar 2007
Posts: 14972

PostPosted: Tue May 21, 2019 1:39 am    Post subject: Reply with quote

The threat is from any application that (1) has permission to access important files that are accessible to you, (2) does not have permission to access important files that are restricted to root (because if it can access those, then it can already do everything, so you've already lost), and (3) would use that access in a way you would not approve. For (3), there are two subcategories: access that you executed by mistake (such as the classic rm -r ​/​), and access by a confused deputy (such as if your browser, due to a bug, allows a malicious webpage to exfiltrate a sensitive file). So if you're confident that you will never, as your unprivileged user, issue a command you will later regret and you are confident that none of the programs you run will do things you will later regret, then go ahead and open up permissions as much as you like. Personally, I don't trust complicated programs that much, so I give them as little access as I can without making my life difficult. The threat model is partly local, but if you run any untrustworthy things that talk to the network, then the threat model extends to whatever untrustworthy inputs can come to those programs over the network.

I don't think you will be able to have a smooth and disruption-free workflow and also keep the security settings restricted to the level I recommend. You can get a good flow, but it will never be as smooth as just opening up the files for direct edit by your existing editor, browser, shell, etc. You could use sudoedit to automate the flow of: (1) copy the restricted file to a temporary file that your user can edit, (2) run your preferred editor as you, on that file, (3) copy the modified file back. If your preferred GUI tool can open a file by having that file named on the command line, you can even use it that way by telling sudoedit to use that as your editor. Since the tool will run as you, all your user-specific preferences will be in effect. The biggest downside is you need to ensure that your tool does not mislead sudoedit into jumping to step 3 early. Many GUI programs, if not told otherwise, will background themselves. sudoedit will misread this as "User has finished editing the file" and proceed to step 3. In the case of gvim, passing -f asks it not to detach, so that the parent (sudoedit) can detect when you are truly finished. Other tools may have similar options. If you run the tool from the shell, and your shell promptly prints another prompt, then the tool has moved itself to the background and sudoedit will end early. If the shell pauses until you quit the tool, then prints your prompt, then the tool remained in the foreground and sudoedit will do the right thing.
Back to top
View user's profile Send private message
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index Desktop Environments All times are GMT
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum