Parrot's user data security discussion

#1

I think we are having some flaw in our current Parrot project. Here is my ideas and solutions. I want to here all of Parrot user about it

Current Parrot (count to 4.6) issue

  1. Our files and folders in $USER are having 755 permission. It means other users can read each other data. For example: 1 workstation user is developing web app, and it has RCE somehow. Attacker can exploit it with www-data permission and access developer data.
  2. We don’t have firejail profiles for our pentesting tools. Check out:
  • Burp Suite has RCE https://www.youtube.com/watch?v=Bv_j8ZsNwl8 .
  • Python library backdoor https://www.bleepingcomputer.com/news/security/backdoored-python-library-caught-stealing-ssh-credentials/ And we must prevent all of this issue as much as possible

So, I am having some suggestions and ideas

  1. For file permissions: set 750 or even 700 by default, as same as hosting systems does
  2. This is complex. We are having thousand tools. Create each profile for each tool is nearly impossible in days or months. And we are having scanners, exploiters, forensic tools, …, user custom tools, unstrusted tools that user download from internet. We can group it:
  • Requires root permission: aircrack, airgedon, …
  • Non root permission:
    • Scan targets, put result to STDOUT. No permission is needed (DNS scanners, …)
    • Need read tool’s config files, their script to execute advance tasks (nmap)
    • Need write file to $HOME as result (wapiti), user define where to write result (airodump) Even we define whitelist and blacklist folder for these tools, I believe tools can read user data in whitelist folders
  • Other tool on internet can be executed normally without sandbox
  • User’s tools, need permission based on user tasks For Non-root permission tools and untrusted tool, I think we can run them under virtual user permission, combine with default file and folder permission in 1. , we can prevent them from reading data in $HOME . All config files and results will be written as virtual user permission. (This is conflict with 700 permission). Other idea is we can create a “virtual” pentest user and stores result in /home/pentest/ -> other problem, pentest user mustn’t be a backdoor.
3 Likes
#2

That’s a very interesting question to discuss, because all Linux systems suffer from this problem.

I am also having some suggestions:

  1. Create a specific directory where ALL local package configs and output can be stored. I suppose naming it 'Metadata' because this directory will contain any data saved and loaded by tools.
    We can reach that by creating a sandbox (with help of firejail, if it provides such functionality) with a virtual $HOME folder, which would link to /home/$USER/Metadata/[tool_name]. To be honest, I don’t know much about firejail, so I hope it can do it.
  2. About handling root and non-root depended apps:

    • Root-depended apps: We’ll have to detect what exactly an app want’s to do and why it need’s root permissions. Mostly tools need root for access to a physical device, i.e. wifi card, graphics card, whatever.
      How? Here comes the worst part:

      • Detect by hands: Group packages by use: { gpu, wifi, … }, and hardcode firejail-profiles to provide access ONLY for needed devices. That is also depends on firejail functionality.
      • Detect by a magic script: Create a magic script which could detect what app is trying to do and what it needs to do it. WARNING. I don’t know how to do it. At the moment I have an only idea to dissassemble it and check for access instructions and let the script create firejail profile.
      • Detect by installation (manual configuration): Well, this method also has a place. We could ask users which access give to a specific tool. I see it as a menu with different options which is being prompted at the first use of the tool. Also we could gather user choices so we can generalize it and ask users if they want to choose default configuration.

Well, if firejail doesn’t provide such functionality, here come’s the sad part . We will have to create an fork of firejail or rewrite sandboxing tool. But I hope we can figure it out.

1 Like
#3

@palinuro - What do you think of this?

#4

NO need to rush this we must complete the idea, create perfect design and then work on it.
I think root-tools are complex:

  • metasploit doesn’t need root to run, but root permission provides default bind port -> more useable
  • We can’t image all cases that tool will be used. For example: airodump use -w <path> to write cpatured file. So, it depend on user path, not static virtual path of @hotwater and my idea
#5

We could prompt a warning message that app is running in a virtual home folder, and that any I/O operations outside that folder will be blocked.

#6

I agree with you both, But
Everything depending on user

And Permission changing ( i love this )

#7

I don’t think it is possible. Firejail can block tasks by default. And even we split data storage, there is no need to make everything be complicated.

#8

I am sorry, what’s so impossible in that? Firejail can manipulate folders permissions, so what’s the problem of simply prompting warning message?
And what you mean by making it complicated? Can we make it simpler?

#9

if use write command like airodump <interface> -w <location> and location is a invalid permission path, so i think airodump won’t run.It needs debugging, this is my theory about this case.
My “simple” is let user write wherever they want. OFC it is conflicting with our idea.

#10

P/s: next case is about forensic tools (reversing, …), data analyzer. They must read user’s data. Even nmap has option that read ip list from a file.
And other case is untrusted apps. I think we can create 1-time-used virtual space for them to protect user data. But…, for example, ghidra, you can block all of data from it (reversing tool). And if it has backdoor (just say that), maybe don’t let it access our pentest data result is good idea (that is why i wrote 1-time-used virtual space

#11

We can do next thing: Create a wrapper to the program, which asks permissions for it (it could be a menu, something like, Allow GPU (yes/no), Allow WiFi (yes/no)), and these changes will be written in a config file, and replace a wrapper with a program running generated config.

Talking simplier - we can ask app permissions on the first launch.

Well, that may sound a little uncomfortable, but all needed files will have to be saved in our 'Metadata' directory. That’s pretty limiting.

Also there is another approach which just came in my mind. What if we create a directory in our /home/$USER folder, i.e. 'Private', and we will restrict any firejailed (sandboxed) program to access it?

This may sound stupid, because it will be a regular folder with the same permissions as others, but if every running package will be sandboxed and will restrict access to this folder, I think we could call it safe for sensitive info.

Of course people still can download .deb packages and install them by hands. In this case it would be nice to alert user that he has to create a sandbox profile for it, or his sensitive information safety will relay only on third-company which maintains this app.

#12

You mean a container…lxc…docker…I believe the term is container. Now as for the scenario first off the real problem is running an untrusted app in the first place, atleast/especially outside a container or malware analysis sandboxing tool. Security begins with the user not the machine, no amount of configuring can stop stupidity.

Someone already basically beat you to it, its called firetools. Maybe you can port/work from that with firejail.

I’ll be honest personally I don’t see any real user data security issue to begin with considering basic security habits should(at least in my opinion) alleviate any real issues. Who would actually want your pentest data? If there’s anything that sensitive don’t enter it at all or encrypt, lock it and remove from the system

#13

we should create a work group for parrot 4.7 to rewrite the parrot launchers, sandbox some important tools and give the proper permissions to most of them.

an interesting improvement would be to create several docker containers for all the tools and create a docker wrapper to put on top of parrot home to turn it into parrot security instead of having the tools installed directly on the system. but there is too much to work on to achieve a similar result, and GUI tools don’t work as expected in docker

2 Likes
#14

Kilian and I are working on shortcut description and tool permission (remove menuexec for normal tools). We will complete them as soon as possible

In my opinion, this is great but I have to notice 2 things:

  • Performance. Run multiple tools shouldn’t has any memory leak or slows system down too much.
  • RCE vulns: There are RCE vulns in docker as i read in the news. We mustn’t let our security feature knock back us
#15
  • palinuro slaps roof of parrot os, RCE slaps back to palinuro *
5 Likes
#16

Can you clarify the docker part?

Are you saying that Parrot Home would be the flagship, and docker would be layered on top to create Parrot Security, or is this just an easier way to transform a Parrot Home install into Parrot Security?

#17

New RC has released
Check it out RC 10
Just before this release I was facing some read-only file problem in some files (like windows SAM)
chmod 777 SAM , chmod +w SAM
Nothing worked
But when they were copied on desktop they were readable.
Think that new RC has Fixed file permission problems
Gonna test it cheers

#18

Yeah I ran through firejail and found out that it really can do that. We could make a research on how to provide access to gpu/wifi/any periphery that need’s running from root. After that step we could firejail most of pentesting tools.

#19

Okay so i think we are all agree default file permission should be 700 or something that other user (on system) can’t reach our user’s data. Now i am thinking container is actually a good idea if we can make an option that user can run any app inside a docker anytime (and ofc virtual space for other tools as i commented above).
I would like to hear suggestion of Whonix devs

1 Like
#20

Docker idea is good ; maybe you guys do

  1. add new user Parronymous
    Where everywhere permission is 000 only mozilla & midori config works
    And also user not in sudo
    This user for browsing && storing data

  2. add service which start anonsurf at bootup

    [Unit]
after=network-manager.service
[service]
User=Paronymous
Execstart=/usr/local/bin/anonsurfExcute.sh
[Install]
Wantedby=multi-user.target`