EasyOS version 2.3.2, June 22, 2020

[BarryK]

Downloading Pyro 1.2.9.1 now to try,

However the reason for the message is that I came across 'proot' the other day https://proot-me.github.io/, ?interesting, get a copy of the current and compile it yourself, that's what everone seems to be doing, the prebuilt are years out of date. Also if you scroll down to the Rootfs tag on the page, it has a link to containers.org's multi bases images, I wonder if they would work with your EasyOS System using a proot container of course to switch with?

EasyOS uses 'pflask' which is a very sophisticated and elegantly-implemented secure chroot system:

https://bkhome.org/news/201809/pflask-c ... roids.html

[vabene]

Hi Barry,
til the kernel 4.xx my big touchscreen - lenovo yoga home - works perfect. Since the kernel-version 5,xx it does not start automatically. the touchscreen-program does not work for me, because it hangs after the first point.
but all necessary modules are there and i found a solution: when i type in the console
- "modprobe hid-multitouch.ko" and
- "insmod /lib/modules/5.4.1/kernel/drivers/hid/hid-multitouch.ko"
(or "modprobe hid-multitouch.ko & insmod /lib/modules/5.4.1/kernel/drivers/hid/hid-multitouch.ko" )
my touchscreen (and the calibrate-touchscreen-program) works again perfect - but not automatically. I have to do the modprobe and the insmod at each booting. is there an chance to get back the auto-calibration for touchscreens?
I wrote this from the new easy pyro 1.2.9.1
vabene

[blgs]

An error boot message occurs during "Copy session to RAM & disable drives"

See attachment for screen picture.

[BarryK]

Hi Barry,
til the kernel 4.xx my big touchscreen - lenovo yoga home - works perfect. Since the kernel-version 5,xx it does not start automatically. the touchscreen-program does not work for me, because it hangs after the first point.
but all necessary modules are there and i found a solution: when i type in the console
- "modprobe hid-multitouch.ko" and
- "insmod /lib/modules/5.4.1/kernel/drivers/hid/hid-multitouch.ko"
(or "modprobe hid-multitouch.ko & insmod /lib/modules/5.4.1/kernel/drivers/hid/hid-multitouch.ko" )
my touchscreen (and the calibrate-touchscreen-program) works again perfect - but not automatically. I have to do the modprobe and the insmod at each booting. is there an chance to get back the auto-calibration for touchscreens?
I wrote this from the new easy pyro 1.2.9.1
vabene

You shouldn't have to run both of those, "modprobe hid-multitouch" will do it (without the ".ko")

I don't know about getting it back automatically. You could put it into /etc/rc.d/rc.local, so it will be retained when you upgrade to later versions.

[BarryK]

An error boot message occurs during "Copy session to RAM & disable drives"

See attachment for screen picture.

Ah yes, that is a non-fatal, just information message. I have appended "2>/dev/null" on that line, to suppress the error message.

Thanks for the report.

[BarryK]

Here is a new tutorial on the "Copy session to RAM & disable drives" boot menu option:

https://easyos.org/user/ultra-secure-web-browsing.html

I posted it last night, then edited it a bit this morning.

For maximum security, you need to be running Easy Pyro 1.2.9.1 or Buster 2.1.9.1, with 5.4.x kernel.

The thing is, is there any way to access the drives? The invitation is open to those with in-depth knowledge of Linux security to have a go at breaking out.

If there is a way of breaking out, then further steps can be taken to lock the user (and any intruder) into the RAM.

One thought is the possibility of getting at the UEFI setup. But the kernel lockdown might prevent that.

[zygo]

Barry,

Why don't you sign your uploads and host the signing key elsewhere?

Z

[ras]

EDIT: and I wonder if there is the possability of having Permanent and separate Temporary Containers. Permanent exist in their own savefile and don't loose parts until deliberately deleted, Temporary are 'cleaned out' when closed.

I have been wishing along the same lines. A desktop container that doesn't keep it's .session unless one chooses to. I know that one can rollback a container to the same effect, but a "save" or "don't save" dialog when exiting the container would be sweet, (with a way to tick a box to make either the default) . One could stay in the same desktop session and have a lite version of "copy session to ram" without having to reboot.

[ras]

Barry,
Did a frugal install of Easy 2.1.9.1 for a quick test to see if I could put a claws-mail .deb into a container. the deb worked fine on the main desktop, but when I created a container for it all seemed well until I clicked on the icon that was created. I could not find /../../claws-mail/container/mnt

Code: Select all

# ec-chroot claws-mail
mkdir: can't create directory '/mnt/sda1/b2/containers/claws-mail/container/mnt/wkg/': No such file or directory
snip
mkdir: can't create directory '/mnt/sda1/b2/containers/claws-mail/container/mnt/wkg/': No such file or directory
gtk-update-icon-cache: Cache file created successfully.
gtk-update-icon-cache: Cache file created successfully.
Executing: DISPLAY=:0  pflask --mount=bind:/mnt/sda1/b2/home/shared:/mnt/wkg/home/shared --keepenv --mount=bind:/tmp/.X11-unix/X0:/tmp/.X11-unix/X0 --no-ipcns --no-netns --mount=bind:/dev/snd:/dev/snd --mount=bind:/dev/mixer:/dev/mixer --caps=all,-sys_admin,-sys_boot,-sys_chroot,-sys_ptrace,-sys_time,-sys_tty_config,-chown,-kill,-dac_override,-dac_read_search,-fowner,-setfcap,-setpcap,-net_admin,-mknod,-sys_module,-sys_nice,-sys_resource --no-userns --chroot=/mnt/sda1/b2/containers/claws-mail/container --  /.control/ec-run claws-mail 
[✘] Could not create mount dest /mnt/sda1/b2/containers/claws-mail/container/mnt/wkg/home/shared: No such file or directory
[✘] Child failed with code '1'
Unmounting: /mnt/sda1/b2/containers/claws-mail/container
Unmounting: /mnt/sda1/b2/containers/claws-mail/.ro0
Container claws-mail stopped

and

Code: Select all

#Information for setting up and running the container

#Connect to X by abstract socket, pipe or unix domain socket (abstract|pipe|unix):
EC_XSOCKET='unix'
#Use Xorg or Xephyr server (xorg|xephyr):
EC_XSERVER='xorg'

#For security, unshare these namespaces:
EC_NS_UNSHARE_MOUNT='true'
EC_NS_UNSHARE_UTS='true'
EC_NS_UNSHARE_IPC='false'
EC_NS_UNSHARE_NETWORK='true'
EC_NS_UNSHARE_PID='true'

#Clear environment variables, except some such as TERM and DISPLAY:
EC_UNSHARE_ENV_VARS='false'
#Tick to run as user zeus in container:
EC_ENV_ZEUS='false'

#Specify what you are allowed to access outside the container:
EC_ACCESS_NET='true'
EC_ACCESS_SND='true'
EC_ACCESS_FOLDER='true'
EC_ACCESS_FOLDER_PATH='/home/shared'

#Drop these Linux capabilities:
EC_CAP_system='true'
EC_CAP_file='true'
EC_CAP_network='true'
EC_CAP_module='true'
EC_CAP_resource='true'
EC_CAP_mount=''

#If security-preset was ever chosen, this is it:
EC_SEC_PRESET='seclevel_3'

#Uncomment if you want to load another .sfs file, resident in the releases folder of the current version of Easy.
#Glob wildcard accepted, in fact is recommended for automatic version updating:
#EASY_LAYER_RO1='devx*.sfs'

will try a couple of different configurations when more time allows

[FeodorF]

Hi Barry!

Found one problem while running 'Buster-2.1.9.1 containerized desk'.

The extra characters '@{[]}..’ don't work - ’ÄÖÜß' do. (f.e. WWW, sakura)

Using easy-2.1.9.1-amd64.img.gz and a BIOS dual core box with German keyboard for testing. (Same problem while running easy-2.1.9-amd64.img.gz) At first run/install I'm using '11' for 'de' keyboard.

[BarryK]

Another tutorial has been written, for developers:

https://easyos.org/dev/coding-for-easyos.html

[BarryK]

There is one little problem if you update an existing installation to 1.2.9.1 or 2.1.9.1

The "Copy session to RAM & disable drives" boot menu requires this in the boot parameters:

Code: Select all

lockdown=confidentiality

So EFI/BOOT/refind.conf in the boot partition will need this:

Code: Select all

menuentry " Copy session to RAM & disable drives" {
 loader /vmlinuz
 initrd /initrd
 ostype linux
 options "rw qfix=cap2 lockdown=confidentiality"
}

For an existing installation, you will have to add this manually.

[rufwoof]

The kernel lockdown feature looks interesting.

For instance if I have a usb attached as sdb and I navigate to /sys/block/sdb/device/driver and do a ls then it shows sym linked folders.

I can unbind that using

echo "2:0:0:0" | tee /sys/block/sdb/device/driver/unbind

(in my case) and sdb (usb) is no longer bound in that kernel session.

If I alternatively do that via /sys/bus/pci/drivers/ehci-pci (and do ls to note the device, 0000:00:12.0 in my case)

echo "0000:00:12:0" | tee /sys/bus/pci/drivers/ehci-pci/unbind

Disables it, but then I can rebind it again

echo "0000:00:12:0" | tee /sys/block/sdb/device/driver/bind

At least that is the case for Fatdog.

lockdown I presume (haven't checked it out yet myself) can prevent access to the likes of the above. But with greater security comes restrictions. I assume with lockdown enabled then it fixes things at bootup and you have less in session (userland) flexibility - even as root.

Personally I prefer the physical approach, plug and unplug a usb stick, and best if you use two sticks, one for boot, the other for data (plugging a boot stick into a potentially compromised running system risks that sticks OS files also being compromised).

If you go down the physical (hard) approach path, then there's no real need (from a single user desktop system perspective) for lockdown. If you use the lockdown (software) approach and attached devices then as ever there is risk of bugs/work-arounds, either present and unknown (or known but not fixed), or yet to come (later releases that fix one problem/bug, but introduce others). Of the two the former (physical) is the better IMO.

I boot Fatdog from usb, that is unplugged during init, isolating the MBR/bootloader/kernel ...etc. I only ever save after making changes from a clean cold booted system (nothing else before or after). Otherwise boot that known 'clean' system, no system changes/saves, and save data separately (incremental saves of data, with off-site copies also being stored). For sensitive operation, such as online banking, boot a clean session, go direct to your bank, nowhere else before or after, cold shutdown afterwards.

Great to see EasyOS having moved in the direction of supporting that style of operation (ability to run totally in ram and leave no remnants)

[scsijon]

Can't seem to install pyro 1.2.9.1 via EasyDD frontend for dd to a Lenovo Thinkpad with a 128gb sata3 ssd in it.

>Clean ssd (nothing installed);
>Created a fresh gpt drivetable;
>formatted as a single partition to test (ok);
>Started EasyDD and picked the 1.2.9.1 ..gz file.

It said it was installing(, in the reverse order to start with)? But at the end, when it said it was finished, I noticed the drive letters for the boot usb had changed from sdb to sdc and only the sdc2 was still on the screen????.

A reboot back into 1.2.9.1, and gparted showed that it was a blank drive (no partitions), any sugestions where to go from here, or have I found you another bug.

I will have a go with 1.2.9 tomorrow and report that (as a Edit: here) in case it's a kernel thing, can't think of what else as it previously it had 0.8.1 which worked ok.


EDIT: 1.2.9 installed without a problem, all working ok, looks like something else to sort out for the new kernel.

[Sage]

Really don't understand why folks persist with the CLI for USB/SD installs? Get a copy of one of the 'majors' loaded up and use the GUI USB Image Writer which seems foolproof. Just got to extract the .gz compression to yield the .img file.
Not quite sure where the Pup is going - it started out as tiny 29Mb, fast basic distro until the clever guys started expanding it with the proverbial Out house sink until, now it's as much as half the size of a major and capable of predicting the end of the world....

[rcrsn51]

Not quite sure where the Pup is going - it started out as tiny 29Mb, fast basic distro until the clever guys started expanding it with the proverbial Out house sink until, now it's as much as half the size of a major and capable of predicting the end of the world....

So keep using the old ones.

[Sage]

So keep using the old ones.

Yes, always at hand!

[BarryK]

The kernel lockdown feature looks interesting.

For instance if I have a usb attached as sdb and I navigate to /sys/block/sdb/device/driver and do a ls then it shows sym linked folders.

I can unbind that using

echo "2:0:0:0" | tee /sys/block/sdb/device/driver/unbind

(in my case) and sdb (usb) is no longer bound in that kernel session.

If I alternatively do that via /sys/bus/pci/drivers/ehci-pci (and do ls to note the device, 0000:00:12.0 in my case)

echo "0000:00:12:0" | tee /sys/bus/pci/drivers/ehci-pci/unbind

Disables it, but then I can rebind it again

echo "0000:00:12:0" | tee /sys/block/sdb/device/driver/bind

At least that is the case for Fatdog.

lockdown I presume (haven't checked it out yet myself) can prevent access to the likes of the above. But with greater security comes restrictions. I assume with lockdown enabled then it fixes things at bootup and you have less in session (userland) flexibility - even as root.

Personally I prefer the physical approach, plug and unplug a usb stick, and best if you use two sticks, one for boot, the other for data (plugging a boot stick into a potentially compromised running system risks that sticks OS files also being compromised).

If you go down the physical (hard) approach path, then there's no real need (from a single user desktop system perspective) for lockdown. If you use the lockdown (software) approach and attached devices then as ever there is risk of bugs/work-arounds, either present and unknown (or known but not fixed), or yet to come (later releases that fix one problem/bug, but introduce others). Of the two the former (physical) is the better IMO.

I boot Fatdog from usb, that is unplugged during init, isolating the MBR/bootloader/kernel ...etc. I only ever save after making changes from a clean cold booted system (nothing else before or after). Otherwise boot that known 'clean' system, no system changes/saves, and save data separately (incremental saves of data, with off-site copies also being stored). For sensitive operation, such as online banking, boot a clean session, go direct to your bank, nowhere else before or after, cold shutdown afterwards.

Great to see EasyOS having moved in the direction of supporting that style of operation (ability to run totally in ram and leave no remnants)

Thanks for the feedback. I will have look around in /sys as you have suggested.

Regarding physical versus software approaches, my method hides ALL drives, including those builtin to the PC. It is the builtin drives that I mostly want to hide.

[BarryK]

Can't seem to install pyro 1.2.9.1 via EasyDD frontend for dd to a Lenovo Thinkpad with a 128gb sata3 ssd in it.

>Clean ssd (nothing installed);
>Created a fresh gpt drivetable;
>formatted as a single partition to test (ok);
>Started EasyDD and picked the 1.2.9.1 ..gz file.

It said it was installing(, in the reverse order to start with)? But at the end, when it said it was finished, I noticed the drive letters for the boot usb had changed from sdb to sdc and only the sdc2 was still on the screen????.

A reboot back into 1.2.9.1, and gparted showed that it was a blank drive (no partitions), any sugestions where to go from here, or have I found you another bug.

I will have a go with 1.2.9 tomorrow and report that (as a Edit: here) in case it's a kernel thing, can't think of what else as it previously it had 0.8.1 which worked ok.


EDIT: 1.2.9 installed without a problem, all working ok, looks like something else to sort out for the new kernel.

You have booted from a USB-stick, which was sdb, and afterward changed to sdc?!!!

That is very wrong, something seriously amiss.

What device name was the ssd? /dev/sda?

EDIT:
Thought about it some more, and perhaps nothing is actually wrong. Drive, letters (sda, sdb, etc) are assigned by the kernel in order in which the drives are found, and the kernel usually finds internal fixed drives first.

If the ssd is suddenly available after bootup, maybe the kernel has decided to reassign the letters. Not what I would expect, but conceivable. No, not what I would expect at all, very odd. Might be 5.4 kernel thing.

You would have been better off, after having created the gpt on the ssd, reboot your usb-stick, and the drive letters will then be assigned correctly.

EDIT:
Thinking about it again, and no, something must be wrong.

[scsijon]

Can't seem to install pyro 1.2.9.1 via EasyDD frontend for dd to a Lenovo Thinkpad with a 128gb sata3 ssd in it.

>Clean ssd (nothing installed);
>Created a fresh gpt drivetable;
>formatted as a single partition to test (ok);
>Started EasyDD and picked the 1.2.9.1 ..gz file.

It said it was installing(, in the reverse order to start with)? But at the end, when it said it was finished, I noticed the drive letters for the boot usb had changed from sdb to sdc and only the sdc2 was still on the screen????.

A reboot back into 1.2.9.1, and gparted showed that it was a blank drive (no partitions), any sugestions where to go from here, or have I found you another bug.

I will have a go with 1.2.9 tomorrow and report that (as a Edit: here) in case it's a kernel thing, can't think of what else as it previously it had 0.8.1 which worked ok.


EDIT: 1.2.9 installed without a problem, all working ok, looks like something else to sort out for the new kernel.

You have booted from a USB-stick, which was sdb, and afterward changed to sdc?!!!

That is very wrong, something seriously amiss.

What device name was the ssd? /dev/sda?

EDIT:
Thought about it some more, and perhaps nothing is actually wrong. Drive, letters (sda, sdb, etc) are assigned by the kernel in order in which the drives are found, and the kernel usually finds internal fixed drives first.

If the ssd is suddenly available after bootup, maybe the kernel has decided to reassign the letters. Not what I would expect, but conceivable. No, not what I would expect at all, very odd. Might be 5.4 kernel thing.

You would have been better off, after having created the gpt on the ssd, reboot your usb-stick, and the drive letters will then be assigned correctly.

EDIT:
Thinking about it again, and no, something must be wrong.

You have booted from a USB-stick, which was sdb, and afterward changed to sdc?!!!

Yes, a 1.2.9.1 stick that works ok too, even when plugged into the laptop in question.

That's what I thought, sdb shouldn't become sdc, but it does when I use 1.2.9.1.

The ssd is sda in both 1.2.9 and 1.2.9.1 usb booting (with sda1 boot and sda2 working partitions with 1.2.9 installed).

You would have been better off, after having created the gpt on the ssd, reboot your usb-stick, and the drive letters will then be assigned correctly.

I have already tried that, no change, still 1.2.9.1 fails.

As I am not actually using the laptop at present (will do in Jan when i start writing again) I'm leaving it for now so both you and I can have a think about it.

It doesn't make sense other than somehow the Disc Partition table is getting ?re-initialised, or is it? as part of the EasyDD frontend proccess (?or does dd do that) even though it's ok with 1.2.9.

Can I have a copy of your new kernel's DOTconfig file please, maybe scanning through it I can see something admiss or newly added.

Oh, and there is nothing in any of the logs (both good and bad) to help, I tried that step first.