Live data from Hacker News

Maestro: A Linux-compatible kernel in Rust

blog.lenot.re

371–380 of 380 posts

Re: Maestro: A Linux-compatible kernel in Rust

#371
post #365
post #363

Earlier quoted context omitted.

I never suggested that it's not possible to bypass them by exploits. In an environment where security matters to such a degree, employees don't have for rights and are not given a choice whether to use such monitoring tools. The (non-)existence of such mechanisms is an important criterion in software selection in such environments. But these places actually have the resources to do this and to actually make use of th…

> don't have for rights should be > don't have root rights

I have been using this security matters to such a degree in my home computers since Windows7 through Antivirus and Firewalls with HISP. It is just a feature that the Windows Kernel provides.

People relies in Matryoshka dolls as tooling, I also do til some degree, but what happens latter when the trojan scapes the Matryoshka ? nobody land, time endless. I use HISP in manual mode because I want to detect signs, and also because I want to limit and to know what benign programs want to access. And I'm talking about this even for simple domestic computers at home!

Needed to say in case a manager who has never used Windows read that:

For to use HISP in manual mode the user really have to want to do it above everything else, literally it is painful and very time-consuming. I've been doing it for more than ten years and even now requires to keep to want it. It is like the difference between walking on sand dunes and walking on pavement when I use other people's computers, so the moment you have no desire for it, the technique is more dangerous than automated mode by far. I mean, in Windows most of the people use it in automated mode (no pop-up), the default mode in antivirus.

My last words, mostly to the rest of the community,

The matter is, the Windows Kernel provides this option of security matters to everyone, and due this the tooling around it, is I guess.

(Although certainly it is mostly through commercial products developed by dedicated teams. And so on.)

Re: Maestro: A Linux-compatible kernel in Rust

#372
post #96

This sounds more than great. Unrelated but at same time related, feel your self absolutelly free to ignore this message, Linux needs a HISP with firewall. I comment it here because this need to be supported by a/the kernel, its needed to limit the functions that allow process injections, and also a way for to canalize all the process executions in a supervised mode. As an [put operative system name here] user, I need…

What do you mean by HISP? That doesn't appear to be a standard acronym. As another user commented though, SELinux would seem to be capable of everything you suggest. You say RSBAC is closer than SELinux but I don't see how it offers anything that SELinux doesn't aside from a few more obscure models.

Whoops! I was mean HIPS, host intrusion prevention system.

I repeated the acronym mistake along all my comments, even in the one I wrote hours ago before notice yours.

Another user commented ptrace. Such comment is the one that should be shown as closer first answer, not SELinux.

Re: Maestro: A Linux-compatible kernel in Rust

#373
post #371
post #365

Earlier quoted context omitted.

> don't have for rights should be > don't have root rights

I have been using this security matters to such a degree in my home computers since Windows7 through Antivirus and Firewalls with HISP. It is just a feature that the Windows Kernel provides. People relies in Matryoshka dolls as tooling, I also do til some degree, but what happens latter when the trojan scapes the Matryoshka ? nobody land, time endless. I use HISP in manual mode because I want to detect signs, and als…

With " HISP " I was mean " HIPS ", host intrusion prevention system.

Re: Maestro: A Linux-compatible kernel in Rust

#374
post #343
post #96

This sounds more than great. Unrelated but at same time related, feel your self absolutelly free to ignore this message, Linux needs a HISP with firewall. I comment it here because this need to be supported by a/the kernel, its needed to limit the functions that allow process injections, and also a way for to canalize all the process executions in a supervised mode. As an [put operative system name here] user, I need…

This is already mostly achievable on Linux with ptrace It's not a popular thing, but there are ptrace-based sandbox implementations. I've written one myself 20 years ago for a very limited use case (sandboxing of programs that are supposed to only read/write from stdin/stout and pretty much disallowed from anything else). From a quick search I found this to be promising: https://developers.google.com/code-sandboxing/…

Thanks, this is the closest to what I was talking about, and that project also certainly sounds promising. This helped.

Re: Maestro: A Linux-compatible kernel in Rust

#375
post #372

Earlier quoted context omitted.

What do you mean by HISP? That doesn't appear to be a standard acronym. As another user commented though, SELinux would seem to be capable of everything you suggest. You say RSBAC is closer than SELinux but I don't see how it offers anything that SELinux doesn't aside from a few more obscure models.

Whoops! I was mean HIPS, host intrusion prevention system. I repeated the acronym mistake along all my comments, even in the one I wrote hours ago before notice yours. Another user commented ptrace. Such comment is the one that should be shown as closer first answer, not SELinux.

Apologies for not seeing your other comments. And I should have known what HIPS means, just a slow day for me I guess.

I would say SELinux is much superior to any HIPS solution though. You can lock down and audit every aspect of a system in detail, more than what most HIPS allow.

Re: Maestro: A Linux-compatible kernel in Rust

#376
post #371
post #365

Earlier quoted context omitted.

> don't have for rights should be > don't have root rights

I have been using this security matters to such a degree in my home computers since Windows7 through Antivirus and Firewalls with HISP. It is just a feature that the Windows Kernel provides. People relies in Matryoshka dolls as tooling, I also do til some degree, but what happens latter when the trojan scapes the Matryoshka ? nobody land, time endless. I use HISP in manual mode because I want to detect signs, and als…

Yeah, that's indeed one of the reasons desktop Linux is not that prevalent in corporate IT networks.

Re: Maestro: A Linux-compatible kernel in Rust

#378
post #369

Earlier quoted context omitted.

Copyleft in no way prevents users from choosing to use alternative software. It merely prevents them from stripping away the associated freedoms for other users.

> Copyleft in no way prevents users from choosing to use alternative software. No, but you arguing every FOSS project should be GPL3 does. You're arguing against alternative licenses here, meaning you're arguing against freedom of people to release software under a license they prefer.

Me arguing for copyleft does not prevent users from choosing to use alternative software, either. It does encourage them, though (which I can only assume is your point). I also didn’t write that every ‘FOSS’ project should use GPLv3.

The freedom I care about (because I think it’s very impactful and extremely important to preserve) is the freedom to use, know, share and modify software. Licensing is a useful tool to help ascertain that freedom, but beyond that, I consider the freedom to choose a licence nowhere near as important.

Re: Maestro: A Linux-compatible kernel in Rust

#379
post #378

Earlier quoted context omitted.

> Copyleft in no way prevents users from choosing to use alternative software. No, but you arguing every FOSS project should be GPL3 does. You're arguing against alternative licenses here, meaning you're arguing against freedom of people to release software under a license they prefer.

Me arguing for copyleft does not prevent users from choosing to use alternative software, either. It does encourage them, though (which I can only assume is your point). I also didn’t write that every ‘FOSS’ project should use GPLv3. The freedom I care about (because I think it’s very impactful and extremely important to preserve) is the freedom to use, know, share and modify software. Licensing is a useful tool to h…

> Me arguing for copyleft does not prevent users from choosing to use alternative software, either. It does encourage them, though (which I can only assume is your point). I also didn’t write that every ‘FOSS’ project should use GPLv3.

You were arguing the project should not be MIT but GPL3 though. Why can't this project use whatever license they like? If not all FOSS project need be GPL3 but this one should, what are some examples of ones that you would be fine with being MIT?

Re: Maestro: A Linux-compatible kernel in Rust

#380
post #378

Earlier quoted context omitted.

Me arguing for copyleft does not prevent users from choosing to use alternative software, either. It does encourage them, though (which I can only assume is your point). I also didn’t write that every ‘FOSS’ project should use GPLv3. The freedom I care about (because I think it’s very impactful and extremely important to preserve) is the freedom to use, know, share and modify software. Licensing is a useful tool to h…

> Me arguing for copyleft does not prevent users from choosing to use alternative software, either. It does encourage them, though (which I can only assume is your point). I also didn’t write that every ‘FOSS’ project should use GPLv3. You were arguing the project should not be MIT but GPL3 though. Why can't this project use whatever license they like? If not all FOSS project need be GPL3 but this one should, what ar…

> You were arguing the project should not be MIT but GPL3 though.

I was arguing generally against permissive licences and in favour of copyleft, without pointing out a specific one, but as a matter of fact I do think that GPLv3 would be a much better choice for this project. (The thread’s OP did name specific licences, though.)

> Why can't this project use whatever license they like?

Why they can’t or why I argue they shouldn’t? Technically they’re able to choose any licence they like, and I argue it should be a copyleft one because I think preserving the four user freedoms is important and not accomplished with permissive licences.

> If not all FOSS project need be GPL3 but this one should, what are some examples of ones that you would be fine with being MIT?

All of the various MIT licences are similarly permissive, right? In that case, I think they make a decent choice for small and relatively simple programs which do not present a great amount of work and could be replicated or imitated without much effort. Programs like True, Hangman, Cowsay or short userscripts.

But if you have a relatively large program, or a project where a great number of such smaller programs work together, I think they ought to be released under a copyleft licence. A new kernel is a good example of such a program, as are core utilities, terminal emulators, media players, web extensions, complex games, etc. So Maestro, seL4, Redox, GNU, Terminology, VLC, mpv, uBlock, Minetest and so on.

I think weak copyleft licences (such as the MPL or the LGPL) can make a great option for programs with a good ethical reason to maximise their usage (including by non-free software). In my opinion, there's seldom a good reason to abandon copyleft altogether. (And as that may imply, it is my view that copyleft should be the default choice. When in doubt, protect your users’ four essential freedoms.)

Post reply on HN