Vào CN, 27 thg 10, 2024 vào lúc 02:52 Anon Loli
<anonl...@autistici.org> đã viết:
>
> I am stepping down to your level only because someone other than you might
> think that you are actually serious and actually put any time and/or effort
> writting your reply.
>
Yes, I'm serious. I write that email on about in 0:20 GMT+7.
Why do I have to write the email instead of sleeping?
>
> On Sun, Oct 27, 2024 at 12:20:01AM +0700, hahahahacker2009 wrote:
> > Anon, I thought you have get out the mailing list of this insecure OS.
> >
> > Vào Th 7, 26 thg 10, 2024 vào lúc 02:25 Anon Loli
> > <anonl...@autistici.org> đã viết:
> > >
> > > On Thu, Oct 24, 2024 at 12:17:25PM -0600, nisp1953 wrote:
> > > > On Thu, Oct 24, 2024 at 11:32 AM Anon Loli <anonl...@autistici.org>
> > > > wrote:
> > > > >
> > > > >
> > > > > OpenBSD does not do compartmentalization like many would love..
> > > > > OpenBSD is not QubesOS.
> >
> > Use QubesOS.
> > Hmm, can any expert here explain why isolation by using virtualization
> > is not secure?
> > Perhaps the answer is "if you can't write secure OS how can you write
> > secure virtualization software", but Anon Loli would reject that...
>
> QubesOS is faaaar from perfect, or even usable.
> One of reasons as to why QubesOS sucks is kindof the point that you tried to
> make.
>
> I agree that their approach to virtualization is far from perfect...
> Current hardware is poor at that, is it not?
>
>
> > > > > The 1st time I heard of pledge/unveil, I thought the same thoughts,
> > > >
> > > > <Snip>
> > > >
> > > > > In my eyes, OpenBSD is not a secure OS, but that is only because I
> > > > > have needs
> > > > > that OpenBSD developers don't deem worthy to fuss over, such as:
> > > > > - anything sensitive or required to exist, on /home/*,
> > > >
> > > > I solved this problem. I created a user account that cannot log into
> > > > root.(it's not in group wheel).
> > > > I changed the directory and file permissions on my regular user account:
> > > > find . -type d -exec chmod 750 {} \;
> > > > find . -type f -exec chmod 640 {} \;
> > > > Any that need execute bits I go back and chmod them.
> > > > Look, here are commands issued from the guest account, where the Go
> > > > modules are downloaded
> > > > (cleetus is my regular login):
> > > > $ ls /home/cleetus
> > > > ls: /home/cleetus/: Permission denied
> > > > $ cd /home/cleetus
> > > > ksh: cd: /home/cleetus - Permission denied
> > > >
> > > > So that guest account is kind of like a sand box.
> > > > I can login to 2 accounts at the same time on my OpenBSD. I do
> > > > Fn+Alt+Ctl +F2 say and I get a
> > > > login at an xterm. I don't need an X window system to write and
> > > > compile code.
> > > > EMACS or Vi will do just fine.
> > >
> > > What I meant by compartmentalization is not account separation, but
> > > compartmentalization for every program.
> >
> > Programs are compartmentalized - they are unveiled. Even chromium do
> > not have access to any directory but your download directory and some
> > selected files in /etc, and full access to /tmp
>
> You do not grasp the meaning of compartmentalization.
> Unveiling and pledging is voluntary, it is literally equal to having laws for
> good people because truly bad people never get caught and thus the law is
> never
> effective, it is only ineffective chains, this is the same.
>
> The true compartmentalization means that, and WAY MORE, always, 100% ON, even
> if the software is malicious by design, from the beginning.
>
So you want access control list or mandatory access control.
Go back to your suckless Linux operating system. It is better.
If you want full system MAC, check out Android.
You want OpenBSD developers to design a "simple MAC system",
and maintain a system-wide MAC policy, and thousand additional
MAC policies for every application in the port.
I vote for Anon Loli to be our mandatory access control expert.
Anon Loli will design the super simple, secure and easy to use MAC
system. Anon Loli will design a system-wide MAC policy that will
remove access to any syscall and file the program do not need,
without any code change in userland programs. That MAC policy
satisfy the need of every port, while being so secure that make
code auditing not needed at all.
> Your creativity is frankly extremely limited as you seemingly never think out
> of the box, in fact you seem to be the merit of slavery that are social norms
> and standards, in physical form, without actual care for actual meanings of
> life and it's possibilities.
>
> Do us a favor and stop wasting out time with your worthless thoughts that are
> not even fully formed yet.
It is YOU have to us a favor, instead of writting emails without code.
>
> > Are you talking about running distributed binaries without pledge
> > and unveil? Don't do that. And mount every partition noexec.
>
> Why not? Let me guess: "It is not recommended?"
> You have a nothing-solving "solution" for everything, just as scripted for
> you,
> do you not?
> Partitions as they are known in the modern world are long deprecated and ready
> for a replacement technology.
Android is the operating system that suit your need.
Full system MAC policy.
>
> > > There are many many things that a program knows about your computer,
> > > including
> > > BUT NOT LIMITED TO:
> >
> > I will see if chromium can do this stuff. Correct me if these problems
> > aren't solved by pledge or unveil.
>
> None of the problems are solved by pledge or unveil.
>
> > > - what programs you have installed
> > no. unveil solved this issue
>
> Not really.
> Unveil is extremely inconvenient if usable at all.
You are denying the fact that Chromium cannot access /bin,
/usr/bin and /usr/local/bin.
You are beating around the bush.
> > > - what you use those programs for
> > no
>
> Why did I think that even after unveil the program had access to say
> /usr/local/bin ?
> According to unveil(2) manual it does not, so that's good.
> Don't get me wrong, this solves just 1 problem from the pool of problems, if
> it
> can successfully be applied to EVERY program, and also binaries which are
> evil.
>
> Again, I am not 100% how a OS with secure pledge and unveil settings for ALL
> programs would look like, would it be usable?
> For example a game only needs to access it's dependencies and their libraries
> as well as it's own files - at it's own place.
>
> > > - when you run those programs
> > yes
>
> ?
>
> > > - dmesg and other hardware information
> > > - hardware access (but thankfully in OpenBSD mic and cam access are
> > > denied by
> > > default)
> > no hardware access -> no graphic
>
> Again, this is only true if the above "tiny binary wrapper" thing can
> successfully use unveil and pledge well.
>
> > > - keylogging
> > X's issue. agree that it is mitigated on qubes
>
> Yeah, I know that it is a X issue, X sucks ass!
>
> > > There is probably a 2x list of things a program can know about you without
> > > having to get root access.
> > > One needs root access usually only to modify core stuff, but one can
> > > destroy
> > > someone's life easily without root, like the xz source-attack almost
> > > defeated
> > > the purpose of open-source software ;).
> >
> > Not the threat for OpenBSD developers.
>
> As said, that is only a delusion.
> Learn to think outside of the little tiny box created for your tiny mind, and
> you will grow. DAMN, this quote literally came from the deceased Terry Davis
> like right now.
Can you leave OpenBSD? We don't need your propaganda here.
>
> If I didn't reply to some paragraph of yours, that only means your reply was
> not good enough.
If I didn't reply to some paragraph of yours, that only means that I don't
have the knowledge required to understand your reply, or I have nothing
to say.
P.S. Think a bit more about my paragraph, I implied many things!
For example, I implied that there are many people who wants to
"protest against Theo's dictatorship", but none succeeded, because
they do not even know who they are.
