Seeking Community Guidance for App Profile Templates in Backup and Firewall Tools (Neo-Backup, Android-DataBackup, Blocker

[Sahil-958]

I am currently navigating the custom ROM space with a focus on applying best practices for managing root access on Android. I am particularly committed to following the principle of least privilege when granting root access to critical tools like device backup and firewall applications.

To this end, I am reaching out to the community for assistance in creating templates for app profiles tailored to backup tools such as Neo-Backup and Android-DataBackup, as well as firewall applications like Blocker.

I have reviewed the relevant documentation, including the KernelSU App Profile Documentation and the official Linux Capabilities Documentation. However, I would greatly appreciate the community's input on selecting the most appropriate capabilities for these tools to ensure both functionality and security.

Additionally, I have examined the root requirements for Neo-Backup as outlined in their FAQ:

• FAQ on Backup Parts and Icons
• FAQ on Root Access Usage

The templates created through this discussion can later be added to the KernelSU template collection, benefiting the wider community.

Your insights and recommendations will be invaluable in ensuring that these tools are configured optimally.

Note: This paragraph was rephrased with the assistance of GPT to enhance consistency and improve overall formatting. This is not an automated abuse of a bot

Thank you in advance for your guidance.

[Sahil-958]

Following are the suggested KernelSU template for Neo-Backup to work properly.
The following info is sourced from the Neo-Backup GitHub issue, along with that the info about groups are sourced from KernelSU's app group descriptions, the capabilities are sourced from the Linux Man Pages.

Mounted Namespace = Inherited
UID = 0
GID = 0

Groups	Info
root	Traditional UNIX root user
install	Group for installing packages
package_info	Access to installed packages details
sdcard_all	Access all users external storage
misc	Access to misce storage
app	Access to app data

Capability	Description
DAC_OVERRIDE	Bypass file read, write, and execute permission checks. (DAC = discretionary access control)
DAC_READ_SEARCH	- Bypass file read permission checks and directory read and execute permission checks; - invoke open_by_handle_at(2); - use the linkat(2) AT_EMPTY_PATH flag to create a link to a file referred to by a file descriptor.
FOWNER	- Bypass permission checks on operations that require filesystem UID of the process to match the UID of the file (e.g., chmod(2), utime(2)), excluding operations covered by DAC_OVERRIDE and DAC_READ_SEARCH; - Set inode flags on arbitrary files; - Set Access Control Lists (ACLs) on arbitrary files; - Ignore directory sticky bit on file deletion; - Modify user extended attributes on sticky directory owned by any user; - Specify O_NOATIME for arbitrary files in open(2) and fcntl(2).
FSETID	- Don't clear set-user-ID and set-group-ID mode bits when a file is modified; - Set the set-group-ID bit for a file whose GID doesn't match the filesystem or any of the supplementary GIDs of the calling process.
KILL	Bypass permission checks for sending signals (see kill(2)). Includes use of the ioctl(2) KDSIGACCEPT operation.
LEASE	Establish leases on arbitrary files (see fcntl(2)).
SETGID	- Make arbitrary manipulations of process GIDs and supplementary GID list; - Forge GID when passing socket credentials via UNIX domain sockets; - Write a group ID mapping in a user namespace.
SETPCAP	- If file capabilities are supported (since Linux 2.6.24): add any capability from the calling thread's bounding set to its inheritable set; drop capabilities from the bounding set via prctl(2) PR_CAPBSET_DROP; - If file capabilities are not supported (before Linux 2.6.24): grant or remove any capability in the caller's permitted capability set to or from any other process.
SETFCAP	- Set arbitrary capabilities on a file; - Since Linux 5.12, this capability is needed to map user ID 0 in a new user namespace.
SETUID	- Make arbitrary manipulations of process UIDs (setuid(2), setreuid(2), setresuid(2), setfsuid(2)); - Forge UID when passing socket credentials via UNIX domain sockets; - Write a user ID mapping in a user namespace.
MKNOD	Create special files using mknod(2).
CHOWN	Make arbitrary changes to file UIDs and GIDs (see chown(2)).

Collaborator Notes

the key is uid=0, apart from that, you can restrict a lot, but have to make sure NB's actions still work:
E.g. I think removing capabilities for audition, oder network related etc. shoudn't be a problem.

Not sure what is different, when you use another uid, in most cases being part of the root group (like in your profile) should have similar effects.
Usually permission management is done via groups.

Note, NB cannot be aware of all the possible combinations. If you use such a profile, you are on your own.
If you want to report an issue, you should first reproduce it with the default profile.
I guess, concrete suggestions (should be PRs) might be accepted.