You are not logged in.
Using the wiki suggestions to upgrade general security, I installed ‘hidepid’. Unfortunately, this breaks anything that requires graphical root authorisation, see here. In my case, it only really affects Gufw, (not a big loss,) and Gparted, which is, (potentially,) a deal breaker. Is there a workaround for this?
Secondly, noting that, apart from the integrated debugger built into Lazarus/Pascal, I have never consciously attached a debugger to any process or run any kind of ptrace, would setting the ptrace_scope flag to 2 be likely to have any nasty surprises. See theYama security docs at kernel.org.
Thanks for your consideration and patience.
Irvine
Last edited by IrvineHimself (2017-04-16 14:34:33)
Et voilà, elle arrive. La pièce, le sous, peut-être qu'il arrive avec vous!
Offline
Add yourself to proc group in /etc/group
Offline
Add yourself to proc group in /etc/group
That worked. I now have 'hidepid' installed and can open Gufw and Gparted. However, a quick test using Firejail tools suggests that 'hidepid' no longer hides process IDs from other applications.
Essentially, prior to being a member of proc, hidepid hid process IDs from my instance of Firejail tools. After joining the group proc, having hidepid installed makes no apparent difference to the ability of Firejail tools to report PIDs.
If I am wrong, I apologise profusely. But, on a single user laptop, the solution would seem to negates the purpose of having hidepid. Ie, hiding process IDs from potentially malicious code.
I would be grateful for further comments, and, once again apologise profusely if I am wrong about the above.
Irvine
Et voilà, elle arrive. La pièce, le sous, peut-être qu'il arrive avec vous!
Offline
How exactly did you check process IDs availability? You can try add 'nogroups' to your firejail instance.
Hidepid still hides processes from daemons that runs as unprivileged user like dnsmasq, openvpn an whatever else you setup. Anyway you can't have both high security and running graphical apps as root
Offline
How exactly did you check process IDs availability? ...
While it does not affect its actual operation, Firejail attempts to keep track of useful metrics like PID, cpu usage, network traffic and memory usage of processes running inside its sandboxes. When I first installed 'hidepid', it could no longer do this. On the other hand, the PIDs were still available through 'apparmor status', (root,) and the 'task manager', (non-root.) Now that my default non-root login is a member of the proc group, the PIDs are once again available to the unprivileged/non-root Firejail.
It's just a quick and dirty test, but it does illustrate the availability of PIDs to non-root processes.
....Anyway you can't have both high security and running graphical apps as root.
On a philosophical level, there is something deeply disturbing about that observation. Though it does seem to be what the evidence is suggesting.
Thanks for your reply, it has given me a great deal to think about.
For the moment I am leaving this open in case others have anything to contribute, and also in case anyone would like to comment on any potential pitfalls in changing the ptrace_scope flag to 2.
Irvine
Et voilà, elle arrive. La pièce, le sous, peut-être qu'il arrive avec vous!
Offline
It's weird that PIDs were visible from non-root task manager, I can't reproduce this in kde.
Keep in mind that while you can see PIDs of apps running inside firejail, those apps can't see any PIDs outside their jails. Firejail protects you from those apps, not those apps from you
Offline
It's weird that PIDs were visible from non-root task manager, I can't reproduce this in kde....
Personally, I have no idea. The functionality of the task manager was one of my biggest worries and, as a consequence, was the first thing I checked. I'm running the Xfce desktop if that helps.
On the ptrace_scope flag: After more research and careful consideration, in my case, it seems that setting it to (2) is, (at most,) likely to affect the ability of applications like Firefox to file accurate bug reports. As a test, I have now set it to (2) and will keep the forum informed of any nasty surprises.
On a related note: Editing /proc/sys/kernel/yama/ptrace_scope using sudo nano doesn't work, the file is reset to (1) at the next boot. To make permanent changes to this file, you need to create/edit /etc/sysctl.d/10-ptrace.conf as follows:
# Created file and added line as part of 'Hardening' see https://wiki.archlinux.org/index.php/security#ptrace_scope
# aditionaly, see https://software.intel.com/en-us/forums/intel-cilk-software-development-kit/topic/280669
kernel.yama.ptrace_scope = 2
For reference, see here
Thanks for your help,
Irvine
Et voilà, elle arrive. La pièce, le sous, peut-être qu'il arrive avec vous!
Offline