Can you point out the reasons sudo is currently needed? For instance, links to kicksecure github sources that depend on it? I am interested in sudoless (and completely passwordless, except for encryption) for single-user workstations, but need to have some idea what I’d be up against if I tried to get that with kicksecure.
See this link… It explains how to get all source code and how to search for some string such as “sudo”:
(This forum theme does not show links very well which will be fixed soonish.)
I did the grep through the sources.
It points primarily to:
which implies that sudo is there as a way to make sure that the installation of kicksecure doesn’t result in admin lockout. That’s a good reason. However, it implies that maybe sudo isn’t needed after installation.
Unfortunately, there are many other uses of sudo in the sources. It isn’t clear to me whether they are for convenience purposes or required.
As for requiring sudo to prevent admin lockout during install: another way would be to make sure that root logins in rescue mode always happen, even if root is otherwise locked. This can be done with a single dropin file:
mkdir -p /etc/systemd/system/rescue.service.d
cat >/etc/systemd/system/rescue.service.d/force-root.conf <<EOF
[Service]
Environment=SYSTEMD_SULOGIN_FORCE=yes
EOF
Then require that the rest of the install of kicksecure be done in rescue mode (probably safer anyway).
Also, on the topic of sudo: has anyone doing kicksecure devo thought about a lighter weight and potentially more secure alternative, like siduction’s doas command? Personally, I’d like to do away with any way to change from one user to another (or root), but I understand that’s not a universal taste.
Oh - kicksecure already has that SYSTEMD_SULOGIN_FORCE dropin file (named override.conf - but the name doesn’t matter). As long as that is put in place first and tested, is there a remaining fear of admin lockout?
It’s probably not needed but you’d need to be a very advanced user to understand, change the source code.
It’s untested and at time of writing there’s no CI test yet to make sure the recovery mode is always functional either.
No contributor was ever working on it and it’s not on the roadmap.
Bug Reports, Software Development and Feature Requests chapter Community Feedback in Kicksecure wiki applies.
It’s not worth pursuing unless there is considerable interest in going sudoless with no root logins allowed (except rescue boots). I’m new here, so I don’t have any idea how much interest there is on this. As an alternative, I noticed that kicksecure puts in protections against brute-forcing passwords. But is there anything kicksecure adds that prevents X key loggers? I don’t know of any such tech short of using wayland with xwayland disabled. But, IMHO wayland environments don’t (yet) provide the stability of X running some tried-and-true window manager. So, if using X, going passwordless is a better way to prevent password attacks.
1 Like
Could you please open separate forum threads for completely separate topics? That’s because this forum is also used as an issue tracker and if something is missing, it serves as a ticket, documents any missing features and might even lead to these features being implemented one day.
1 Like
Back on topic: Sudoless Kicksecure. Addressing the issue about how robust the rescue boot forcing root logins is by having an alternative way to get to root that is just as secure as a rescue boot, and more secure than sudo, su, polkit, etc. as those are all susceptible to programmatic attacks by malicious software, and to misconfiguration errors.
Below is a very small C program for a suid exe that will open a root console and switch back when the console exits. This is a secure way to get to root during a normally booted (non-rescue) X or console session, and works even if the root account is locked. I have tested that it works, and it seems secure on my own judgement, but would appreciate other opinions. Obviously, if on a multi-user system use file permissions to only allow execution by users who can be trusted with root capabilities.
#include <fcntl.h>
#include <unistd.h>
#define OPENVT "/usr/bin/openvt"
/* Establish a very basic and safe environment for the VT session. Note:
* if we don't set SHELL, then a very simple attack would be to set SHELL
* to a malicious exe and run this suid, with the result that the malicious
* exe would get root privileges. */
char *vtenv[] = {
"PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin",
"SHELL=/usr/bin/bash",
"TERM=linux",
"LOGNAME=root",
"HOME=/root",
"USER=root",
NULL};
int main() {
/* really become root: */
setreuid(0, 0);
setregid(0, 0);
/* null-out stdin,stdout,stderr to prevent redirect-IO attacks: */
int nullfp = open("/dev/null", O_RDWR);
dup2(nullfp, 0);
dup2(nullfp, 1);
dup2(nullfp, 2);
/* openvt options used:
* -l makes it a login session by prefixing the shell with '-'
* -s switches to the VT
* -w waits for exit from the VT and switches back
* The problem with using -e /usr/bin/bash instead of setting SHELL to /usr/bin/bash
* is that -e interferes with -w.
* */
execle(OPENVT,OPENVT,"-lsw",NULL,vtenv);
return 0;
}
Interesting!
This is giving a root shell but not requiring any authentication?
So you’re working on a sudo alternative?
I am not sure how that fits in here.
How do enable networking functional from rescue mode? It’s likely possible but I think it’s undocumented and non-trivial to research.
The next planned evolution of Kicksecure is however proving an ISO installation method (easier).
I won’t be working on installation distribution morphing during Debian recovery mode.
Interesting!
This is giving a root shell but not requiring any authentication?
So you’re working on a sudo alternative?
I am not sure how that fits in here.
I am considering going sudo-less with root account locked, and I don’t know how much of kicksecure I can incorporate into that. This openvt suid code is probably how I will proceed, as I now consider it a better alternative than rescue mode, as I can use it during normal operation without rebooting. My point to posting it is to show that rescue mode does not need to be the only way to do root tasks when going sudo-less with root locked. If relying on an unproven rescue mode was the original reason for the reluctance to do a sudo-less Kicksecure.
That is a very easy systemd setting. Also, I think in recent Debian, including bullseye, it is the default, so no research is needed.
1 Like
Is it possible that installing Kicksecure disables this? I have 3 Debian bullseye VMs, and the 2 that don’t (yet) have Kicksecure have networking in recovery mode - specifically, the ifup@ens3.service is active. And apt update works. But the VM with Kicksecure does not have networking by default in recovery mode. Was that done intentionally or by accident?
The easy way to fix it is to add a networking service wants link for the rescue target:
mkdir -p /etc/systemd/system/rescue.target.wants
ln -s /lib/systemd/system/networking.service /etc/systemd/system/rescue.target.wants/
1 Like
That must be by accident. At time of writing, there’s no extensive changes to recovery mode by Kicksecure.
In my experience, recovery mode is non-networked by default. Kicksecure didn’t change this. Might be dependent on the Linux distribution, default desktop environment and there packages they pull.
This would need to be developed as a standalone project for wider input. Otherwise the attention it’s getting only here will be too low.