You are not logged in.
Using Beowulf for a text mode console only server too, though just debootstrapped it from console on another Devuan Ascii instead of upgrading.
IMHO debootstrapping Devuan is the most convenient method to get a new Devuan installation.
Now the server runs Libre Kernel, ZFS, Alpine Linux as a KVM guest, very stable after enabling firehol DDOS protection like:
ipv4 synproxy input inface eth0 dst 95.129.163.132 dport 25 accept;
interface eth0 Mobo;
protection strong;
protection all-floods; # 90/sec 40;
protection connlimit 150 mask 24; # from all
Would not it be easier to produce Devuan release without GUI earlier than with GUI?
Do most of us really need Devuan versions newer than v2.1 ASAP on a dekstop ?
As for me I am happy with Ascii v2.1 + Trinity Desktop and can run anything I need in a KVM still displayed on the main system Xorg. Currently I use Devuan v2.1 for Xorg desktop but in the future it is possible to use even a dedicated OpenBSD for a few more secure screens.
For me it would be more preferred to have server releases of Devuan ealier than desktops, like:
Devuan Beowulf v3.x Server Edition with text only console tools and what is the most important server packages like apache, dovecot, etc.
Why not to unify developer's forces of distros like Devuan, Alpine, Slackware and Gentoo/Calculate into a single job stream of cleaning important server packages from nasty systemD? You could create OpenRC definitions of missing servers together in the future.
Though most likely it is how Debian distro works. Is there any way to reduce this amount of suids without chmod?
/var/local
/var/mail
/opt/brave.com/brave/brave-sandbox
/usr/bin/ssh-agent
/usr/bin/bsd-write
/usr/bin/dotlockfile
/usr/bin/newgrp
/usr/bin/chage
/usr/bin/expiry
/usr/bin/crontab
/usr/bin/gpasswd
/usr/bin/dotlock.mailutils
/usr/bin/pkexec
/usr/bin/bwrap
/usr/bin/chfn
/usr/bin/passwd
/usr/bin/sudo
/usr/bin/wall
/usr/bin/chsh
/usr/lib/mc/cons.saver
/usr/lib/policykit-1/polkit-agent-helper-1
/usr/lib/eject/dmcrypt-get-device
/usr/lib/xorg/Xorg.wrap
/usr/lib/openssh/ssh-keysign
/usr/lib/x86_64-linux-gnu/utempter/utempter
/usr/lib/pidgin-blinklight/blinklight-fixperm
/usr/lib/dbus-1.0/dbus-daemon-launch-helper
/usr/local/lib/python2.7
/usr/local/lib/python2.7/dist-packages
/usr/local/lib/python2.7/site-packages
/usr/local/lib/python3.7
/usr/local/lib/python3.7/dist-packages
/usr/local/share/sgml
/usr/local/share/sgml/declaration
/usr/local/share/sgml/misc
/usr/local/share/sgml/entities
/usr/local/share/sgml/dtd
/usr/local/share/sgml/stylesheet
/usr/local/share/fonts
/usr/local/share/texmf
/bin/ping6
/bin/su
/bin/mount
/bin/umount
/bin/ping
/bin/fusermount
/bin/ntfs-3g
/sbin/unix_chkpwd
Please note, that this approach only works for older Nitrokey Pro device, not Nitrokey Pro 2 (all devices purchased before 04/04/2018).
Why not reviewing a Devuan with Trinity desktop environment?
https://cdn-12.anonfile.com/yee0r2A7nf/ … utlook.jpg
Click on the image for a full size.
Sounds like a good idea but wouldnt that be allowing Nitrokey to handle sensitive info? Its kind of like VPN, you are trusting an outside source to secure your credentials, just hope they are good enough i suppose. Interesting question though.
Nitrokey Pro2 and FST-01 tokens do not transfer any sensitive info via Internet, they even do not transfer it to your computer, they keep your personal generated private keys withing it selves never extracting them. The private keys are generated INSIDE the token and never leave it even over USB.
That is the main reason to get such keys for maintainers to avoid bigger problems even if their computers are partially hacked.
Please take into account an existence of fully invisible boot kits activated from BIOS and running in negative rings of CPU.
It is not possible to detect them and even not possible to erase them by reflashing BIOS from the computer due to virtualization protection often integrated into such bootkits. Need to use an external reflashing device attaching it to motheboard BIOS chips to clean out from this type of a malware to prevent active bootkit
protecting itself from erasing it from BIOS chip.
All users of a distribution can get a damage if developers keys stored on general disks are stolen.
But it applies to Debian too, for a protection it would be preferred both Debian and Devuan developers would get Nitrokeys.
Actually all active developers of useful open source software on Github like repositories shall get Nitrokeys to protect user's community.
Though Nitrokey uses open source software to build its firmware it seems like it is not customize-able and even not update-able at least in Pro2 model.
There is a completely free FST 01 hardware to get a similar functionality:
https://www.gniibe.org/FST-01/fst-01.html
Online FSF.org shop for ordering:
https://shop.fsf.org/storage-devices/ne … -generator
Its firmware can be changed from a random number generator to GNUK to become a cryptographic token.
There is an opinion about Nitrokey vs FST-01:
https://news.ycombinator.com/item?id=11693888
IMHO if you trust Nitrokey company a non update-able Nitrokey Pro2 firmware looks like even a more secure than an update-able FST 01.
To protect even from government agencies FST-01 or a custom made from some older SoC like ARMv5 or earlier may be better in terms of security,
Nitrokey is a type of a dedicated microcomputer specialized for cryptographic operations.
So it is possible to keep your private keys inside Nitrokey and never export or extract them.
Internal Nitrokey hardware and software supplied required OpenSC APIs for doing encryption and singing.
It is declared as difficult (or impossible) to pawn Nitrokey internals from an outside trojaned computer where it is attached to.
Anyway I would suggest a mechanical switch to break USB cable line like a chinese washing machine timer to connect Nitrokey only for a few minutes just to create a new session like SSH or GPG.
For example Gentoo developers got Nitrokey Pro 2 keys to secure their distribution.
For example a brave browser can run in a beowulf VM and still render its GUI on Ascii host by the following command:
ssh ice "brave-browser &";
Then you will have super stable ascii host with its Xorg server
and beowulf and ceres simultaneously running in different KVM vms for experiments with fresher GUI programs while they are still not released as stable.
Btw, this config has defended me from Ganstalkers' EMI and browser plugin attacks even on a slow HDD as ZFS vdev without any SSD caching:
https://web.archive.org/web/20191106043 … ssues/9518
VM specific datasets are:
zfs set sync=disabled
for performance, having regular snapshots of course to rollback if a dataset gets any corruption due to unexpected reset, power loss, etc.
With a SSD it would work even faster which would be noticeable at least during computer power on when ZFS caches are cold yet, but after an hour of work HDDs become fast too after ZFS ARC gets already hot enough.
And a high IO attack from browser plugins becomes useless. Computer cannot be hung anymore by this method.
ceres.sh:
set -x;
SystemDev=/dev/zvol/XXX/ceres_vol;
chmod 777 $SystemDev
MemSize=4096;
#Modem=" -device usb-host,vendorid=0x0abc,productid=0x1234 ";
Network=" -net user,hostfwd=tcp:127.0.0.1:YYY-:22 ";
Drives=" -drive format=raw,if=virtio,aio=native,cache.direct=on,file=$SystemDev ";Options=" -m $MemSize $Modem $Network $Drives ";
sleep 1s;
/xxx/kvm.sh "CERES64" $Options;
kvm.sh:
#/bin/sh
set -x;
Name=$1;
QEMUOptions=${@:2};
#exit;
VENDOR1='68:5d:43' # Intel
VENDOR2='00:17:A5' # Ralink
RANGE=256;
rangen()
{
NUM=$RANDOM;
let "NUM %= $RANGE";
OCT=$(echo "obase=16;$NUM" | bc);
# Single (low) values prepended with '0'
if [ ${#OCT} == 1 ]; then
OCT='0'$OCT;
fi;
echo $OCT;
}
gen_random_mac()
{
# perl -e 'for ($i=0;$i<6;$i++){@m[$i]=int(rand(256));} printf "%X:%X:%X:%X:%X:%X\n",@m;';
# dd if=/dev/urandom bs=1024 count=1 2>/dev/null|md5sum|sed 's/^\(..\)\(..\)\(..\)\(..\)\(..\)\(..\).*$/\1:\2:\3:\4:\5:\6/';
A=$(rangen); B=$(rangen); C=$(rangen); D=$(rangen); E=$(rangen); F=$(rangen);
echo ${VENDOR2}:${D}:${E}:${F};
}
chmod 777 /dev/kvm;
MAC=`gen_random_mac`;
modprobe kvm;
modprobe kvm_intel;
#KernelOptions=" console1=ttyS0,115200 ";
KernelOptions=" root=LABEL=$Name MY_LOCATION=$MY_LOCATION ";
KernelDir="/XXX/Security/Devuan/Kernel";
#echo \
nice -n 7 ionice -c 2 -n 7 /usr/bin/qemu-system-x86_64 \
-smp 2 \
-k en-us \
-machine accel=kvm \
-no-fd-bootchk \
-virtfs local,id=shared_folder_dev_0,path=/download,security_model=none,mount_tag=shared0 \
-kernel $KernelDir/$Name/vmlinuz \
-initrd $KernelDir/$Name/initrd.img \
-append "verbose net.ifnames=0 ipv6.disable=1 ro quiet framebuffer=false selinux=0 console=ttyS0 zswap.enabled=1 zswap.max_pool_percent=25 zswap.compressor=lz4 $KernelOptions " \
-rtc base=utc \
-name "$Name" \
-net nic,macaddr=$MAC,model=virtio \
-usb \
-device usb-ehci,id=ehci \
$QEMUOptions \
-serial mon:stdio -nographic;
Hello,
As for me I have found it very convenient to stay at Devuan Ascii on the host and run both Beowulf and Ceres in KVM virtual machines.
I am connecting to beowulf and ceres virtual hosts via ssh -X
and then start graphical application in VMs while displaying their output on Devian Ascii + Trinity, very nice, even browsers work fine anf fast enough to refresh screen. May be later I will have a dedicated X server in OpenBSD while continuing to use Devuan Ascii for hosting VMs and keep them in ZFS pools.
.ssh/config:
Host beowulf ice ceres
User ice
Ciphers aes128-ctr
Compression yes
CompressionLevel 9
ForwardX11 yes
IdentityFile /xxx/client_key
# ForwardAgent yesHost beowulf ice
Port YYY-1Host ceres
Port YYY
And names: beowulf ice ceres
are specified as 127.0.0.1 in /etc/hosts
Can anyone please suggest a good small and light boot loader to choose a kernel like GRUB on X86?
It seems GRUB2 cannot be run without EFI?
Does not it look insecure to boot so many layers like complex EFI and then complex GRUB2 from it?
I would like an easily customizeable boot loader like grub1 or grub4dos which would be started from U-boot boot.scr instead of a kernel.
Easy syntax to add more kernels and other executables would be very welcome.
The idea is to get a chain of boot loaders like this:
BROM (in SoC chip) -> U-boot->Something like grub4dos with customizable menus -> choosen kernel, preferably capable to start any OS (compatible with a specific board) like OpenBSD or Linux
This has been tested on Cubietruck board.
Devuan v9 ASCII in text only mode with a minimum amount of services enabled, actually only SSH, eudev and tty for login sessions.
The latest backports for Devuan stable applied.
The latest Libre deblobbed kernel v5.3.1 is bootable fine from an U-boot taken from the latest prebuilt Arch Linux for this board.
May be it can save a few days or weeks of time of learning for newbies on how to get Devuan ARM bootable with the latest kernel.
And it is fully verifiable by debsums:
wajig integrity 2>&1
passes fine
Download URL:
https://cloud.mail.ru/public/5d1U/4EwwaFs5D
Just unrar and dd it to a microSD (which is at least 4Gb in size or more) and insert into the board to boot.
dd if=devuan_ascii_for_cubietruck_dd.img of=/dev/sdX
Login: root
Password: devuan
Anyone could see just an idea about how to boot from this image and build his own by himself.
Actually it is tested only on Cubietruck yet, and missing many dtbs in /mnt/boot/boot/dtbs directory, just copy them manually from /mnt/boot/_other if needed. VGA port does not work, but HDMI to VGA adapter works fine even with a very old 15" display via its VGA port.
It may be a good start to install and configure some services like e-mail, TOR, I2P, chat (jabber or matrix) on a relatively more secure board like ARMv7 is compared say to X86 (which has many different backdoors and flaws) with a more secure kernel like deblobbed (without proprietary firmwares) Libre kernel v5x.
The only blob you get when running this config is a BROM (Boot ROM BLOB about 32Kbytes in size or about it) which is flashed into the SoC chip on the factory and it cannot be modified by end users at least without secret proprietary documentation. It is one of the most deblobbed things which can be got for that money ($10-$100).
Hopefully it will be used by good guys for example for defending human rights.
Good Luck.