Hide existence of sysmaint from non-sudors?

Support
1

Directly hiding a specific home directory like /home/sysmaint from ls /home is challenging because /home is typically world executable (mode 711 or 755), allowing directory listing even if individual homes are private. Non-root users can still see directory names via ls /home. Complete hiding requires mount bind tricks, separate filesystems, or containers. No simple chmod.

Present view access mode of /home/sysmaint from non-privileged viewpoint: \

[user ~]% chmod-calc /home/sysmaint                                       
Permissions for: '/home/sysmaint'
Type: Directory
Owner: sysmaint
Group: sysmaint
Octal Permissions: 750
File Size: 4096 bytes
Link Count: 11
Hidden File: No
ACLs: none
Extended Attributes: none
Capabilities: None
Immutable (chattr +i): No

Symlink: No

Parent Folder Symlink: No

Category   Read   Write  Execute 
Owner      Yes    Yes    Yes     
Group      Yes    No     Yes     
Public     No     No     No      

Special Attributes:
SUID: Not Set
SGID: Not Set
Sticky Bit: Not Set
[user ~]%

Can we use separate mount namespaces to effectively hide filesystem artifacts and process details associated with a sysmaint, while preserving the underlying permissions and capabilities. Cause currently by the design on linux in general and on Kicksecure with user-sysmaint-split.

Example commands that get what I mean here when booted in User mode:

[user ~]% ls /home                 
sysmaint  user
[user ~]% 

[user ~]% id sysmaint >/dev/null 2>&1 && echo "exists" || echo "not found"

exists
[user ~]% 

[user ~]% getent passwd sysmaint
sysmaint:x:1001:1001::/home/sysmaint:/usr/bin/zsh
[user ~]%

However find can see sysmaint existence:

[user ~]% find -user sysmaint 
[user ~]% find /home -user sysmaint
/home/sysmaint
find: ‘/home/sysmaint’: Permission denied
zsh: exit 1     find /home -user sysmaint
[user ~]%

Further case: In Qubes Kicksecure disposable VMs, uptime -p displays: \

[user ~]% uptime -p
up 0 hour, 0 minutes
[user ~]%

However in Kicksecure you get something like: \

[user ~]% uptime -p
up 1 hour, 34 minutes
[user ~]%

I know this related to isolation via virtualization but I was wondering if we could achieve something similar for non sudo users if eve possible without being security theater cosplay or pointless?

Noted executing ps aux under user revealed no traces signaling sysmaint’s operation via active threads, by the way.

Moreover, post login as standard/persistent user, then opting for logout (not a shutdown), the login screen display rejected “sysmaint” as user does not exist. Precisely how does sysmaint mask itself from regular users during login authentication from non sysmaint boot?

2

I don’t really understand how hiding the existence of the sysmaint account from other account is useful. Like you demonstrate, there are many different ways of telling that an account named sysmaint exists. A fundamental assumption made by most applications in the Linux ecosystem is that the existence of any user account on the system is public knowledge to any (non-sandboxed) application running on the system. Kicksecure does nothing to change this, but it does already do a number of things to make this knowledge rather difficult for an attacker to use. See:

The way user-sysmaint-split is designed, no processes should be running as account sysmaint when booted into a user session, and no processes should be running as a standard, non-sysmaint account in a sysmaint session unless the user manually runs them using sudo -u user ... or similar. This means there is no inter-process communication attack surface that could be used for a malicious process to elevate its privileges to sysmaint.

Even if it was possible to hide the sysmaint home folder’s existence, scrub it from databases, and otherwise make it vanish from the system, malware would still be able to know that the account existed because the package user-sysmaint-split is installed. At that point we’d have to start messing with the internals of apt to hide what packages are and are not installed, and messing with a bunch of other places in the file system to hide files indicating that user-sysmaint-split was installed. This would not only be a profound amount of work, it would also potentially break parts of Kicksecure that check if user-sysmaint-split is installed and modify their behavior if so.

tl;dr: I can’t see a use for this, and I think it’s impossible. The threat model I think you have in mind however can be dealt with, and there are already steps we’ve taken to defend against it.

1 Like