777 is dangerous and meaningless if you don’t know exactly what you do, and chmod +x does not fix read-only issues, try with +w instead as you need to add write permissions, not execute ones
2 Likes
oh sorry type mistake not chmod +x
I tried chmod +w but not working
It is good, but I don’t think it’s right.
We need to create something similar to docker, but don’t use it. Because we’ll have to use docker images and wrap them in firejail, it’s complex and not exactly how I personally see it.
I think that forking firejail and improving it’s functionality with granting access to gpu, wifi card and e.t.c what needs to be run with root.
S1udge told me firejail can do it all. We can avoid docker if we can control firejail fully
Yes, firejail is really powerful and can do most of we was discussing right here 
.
But as you already said some pentest toools need root for accessing physical devices.
Can firejail grant access for these devices only, without granting root?
If so, we have to stick with it, read more docs and wrap everything around.
If not, we’ll have to fork firejail and make this real.
2 Likes
Tools NEEDS root permission because that is how it work. You can’t do, for example: create UDP packets, without root permisison
Why not 
? What’s so privelege in creating UDP/IP packet? I will tell you that binding a socket to a port doesn’t require permission, if it’s not a system port. (I am learning C sockets atm).
We know that everything in UNIX is a file. So to grant access to some device we need grant access to it’s “controlling file”. I am not sure, but that is how it has to work.
1 Like
No well something you not able to set without root ,
Security tools required root
I am talking about granting root to firejail, but not to pentest tool.
As I’ve said previously, everything is being controlled by files and file descriptors.
So let firejail run from root and grant access for pentest tools to specific files which control physical devices.
Another problem that we may face is that pentesting tools do a root-user check. We can probably somehow fake root user.
But this is a problem of programs, they shouldn’t ask root but ask access for device-controlling files.
i think pentest tools should be run as root as usual without limitations.
a penetration tester should do some isolation between its working environment and its home system, and firejail is not the proper tool to do that. Running other parrot instances in virtual machines or through docker is way better
S1ludge thinks firejail can run app in other user’s permission. I believe there are tools don’t need root permission at all and no need to add more permission (we can think about security risk if tools aren’t updated and they have 0days). But if tools have root permission inside docker, I think it is okay.
It is about permission, not username. Even we don’t limit access of a tool to a device, it still needs root permission to execute the code (for aircrack and other tools that need root permission).
I am talking about some programs have userID check (root is 0).
I think that we should maintain ParrotOS Home+Pentest system idiom, because if you say there has to be isolation between home system and working environment, what’s the target of ParrotOS then?
Why should notepad have permission to gpu fan’s? Why should vim have permission to, i.e turn off your computer? It is possible, if anybody hack’s any app/package.
Probably firejail is not a proper tool, then we should create one.
There is an interesting question: Why not everything runs from root?
Because it simply doesn’t need to.
never seen a computer compromised because vim was exploited… let’s keep our focus on important things and let’s try to not over-engineer things all around.
10 development hours dedicated to make vim more secure are 10 hours not dedicated to fix libreoffice crashes or firefox security
2 Likes
-
Better is don’t isolate any pentest tools
If do, then bunch of error is going to be take place . -
it become more insecure
The work which only root able to do. Is user can done it. Then no sense left
Then getting proper root shell is become more easy as examplesudo nmap --interactive (old version)
It won’t ask you password
You get root shell, able to delete and make files in root ,
So, better is current situation. Again depends on $user
If you have never seen it, it is still not a warrant that it can’t be exploited. We shouldn’t rely on third-company security, because if you say so, what’s the point of firejail then? If we started sandboxing apps we should sandbox everything.
Man, that’s meaningless. Have you done it? Do you know that many errors will pop up?E
Difference between user and root is only in file permissions. I can’t see any problem.
However, I am going to fork firejail or create something similar with additional access to physical devices controlling file, I can’t see any I see no reason why we shouldn’t do it.
UPD: Actually it is about getting file paths for this files and granting access in firejail.
If firejail can’t fake root, we should do it. That’s ALL.
I think firejail supports “fake root” mode. If we can make it work then it will be great. But there will be security issues: if firejail can access hardware as root permission, will it be exploited and gained root permission for malware? But that is a little far from our hardening idea.
Currently Kilian and I’ve completed descriptions and we are reviewing tool permissions. I may edit tools, create other log file destination so tools won’t ask root permission for saving log files in /usr/share/tool-folder anymore.
This topic was automatically closed 120 days after the last reply. New replies are no longer allowed.