theporgs/roadmap

Public roadmap of the Exegol project

roadmap's Issues

Network enhancement

Refacto of the current network settings and capabilities of Exegol

Sound sharing support

New backup action

The needs

Implement a backup feature allowing the user to simply backup some data before removing a container.
"some data": mounted volumes (e.g. /workspace), command history, trilium data, home directories, responder db, crackmapexec db, some tool logs etc.
The data can then be saved in an encrypted archive/container/whatever

Improve entrypoint

Easy wrapper install

Create a wrapper install script that would allow something like

curl https://github.com/Exegol/install.sh | bash

CI/CD pipeline (resources)

Setup GitHub Actions workflows for updating the resources regularly, at each commit, and test pull requests

Custom dockerhub registry

Have the registry, (and user/password if needed) configurable in the user config so that Exegol users can work with custom, pre-built, images.

Hardening / Lockdown mode

Have a local firewall, limited capabilities, virtual env around docker on the host, non-root user inside Docker, and many more security enforcement to be able to use Exegol in sensitive contexts, limit operational security risks, etc.

Voting system for new tools

We would like to find a way to be able to have an opinion from users on the new tools that will be installed/removed/tweaked/etc. on Exegol.

See it as a voting system where users can give their input.

For instance, we could setup a periodical vote where every X days (could be once per month p. ex.) users can go to the voting platform/system/whatever and identify the tools they want added/removed/kept/etc.

Any idea is welcome here, we're open to suggestions on anything, especially on that matter

Remote graphical desktop

The needs

Currently, Exegol is a 90% command-line interface, with some GUI apps on top (when display sharing is possible). It poses two issues

1. users that can't use display sharing cannot run GUI apps
2. there's no desktop, which is fine for most users but lacking user experience for the not-so-advanced users

Description

In my opinion, the best way to have a modern graphical interface fit for Exegol would be to have an in-browser desktop.
I'm thinking Apache Guacamole / webtop and similar solutions. No idea how to implement this yet. Most of the implementation would probably be on the Exegol-images side, and the wrapper would only need to integrate an option like --desktop and would return the URL where the desktop can be reached. Open to suggestions for this.

Alternatives

No response

Additional context

No response

GPU sharing support

Adding an option to automatically share the host GPU to the exegol container

Handle FIDO2/security keys

The needs

When using security keys for GitHub signing & authentication, the git command line requests confirmation of user presence as shown in the screenshot below.

When using the wrapper, there's nothing shown.

Also, when the physical device is not connected, the wrapper errors without indicating why.

It'd be great to improve the UX on this, within the limits of what's possible through the libs ofc.

Description

n/a

Alternatives

No response

Additional context

No response

Python

Wayland support

Support for WAYLAND graphical environment

Encrypted volume/filesystem support

The needs

No response

Description

It'd be awesome to interface with LUKS or similar alternatives to handle encrypted volumes.
This would be an option at the creation of the container, to have the workspace volume (and possibly the other part of the container filesystem) encrypted with LUKS (or something else) and a key set by the user.

It would look like this at the creation of a new container

1. exegol start container image --luks
2. wrapper asks for the symmetrical key
3. wrapper creates and mounts the volume(s) (workspace, and container fs if possible)

It would look like this at the start of an existing container

1. exegol start container image --luks
2. wrapper mounts the encrypted volumes
3. asks for the key and decrypts them

Open to suggestions

Alternatives

No response

Additional context

No response

New images (forensic, mobile, wifi, ...)

Create more dedicated images for mobile apps testing, forensic/incident response, phishing (?), red teaming, wifi/radio, CTF, etc.