← Home ← Back to /g/

Thread 106498514

110 posts 20 images /g/
Anonymous No.106498514 >>106498520 >>106498805 >>106498890 >>106498978 >>106498990 >>106499228 >>106499553 >>106501363 >>106502639 >>106502651 >>106502653 >>106502740 >>106505077 >>106505519 >>106506181 >>106508516 >>106508630 >>106508940 >>106509239 >>106509477 >>106509574 >>106511455 >>106519270
Why don't linux systems protect themselves against malware?
Security by obscurity is the dumbest shit ever.
Anonymous No.106498520 >>106498776
>>106498514 (OP)
>say random nonsense and retards(OP) will believe it
Anonymous No.106498776 >>106499165 >>106502730 >>106506134
>say random nonsense and retards(>>106498520
) will believe it
Anonymous No.106498805 >>106503433 >>106507432 >>106518262
>>106498514 (OP)
It's like he knows absolutely nothing about Linux.
Here's your Mac System Integrity bullshit:
https://wiki.gentoo.org/wiki/Integrity_Measurement_Architecture
Anonymous No.106498890 >>106503526 >>106513787
>>106498514 (OP)
>Security by obscurity is the dumbest shit ever.
Anonymous No.106498978
>>106498514 (OP)
you see if I weren't working on a monitoring solution focusing specifically on linux systems I would have believed you
Anonymous No.106498990
>>106498514 (OP)
Ignoring the fact that it's not just security through obscurity, and that there are tools. Lets also talk about how many Linux users also know their computers. And knowing your computer is the best way to notice suspicious shit, and protect yourself manually.
Ever wonder why an IT person will get fewer viruses than the average mac using stacy? Regardless of their OS?
Anonymous No.106499165
>>106498776
based
Anonymous No.106499228
>>106498514 (OP)

they donΒ΄t

install like vuescan and they take a sip of springwater
Anonymous No.106499553
>>106498514 (OP)
what's the use case for security?
Anonymous No.106501268
>loonix
Anonymous No.106501363 >>106501760
>>106498514 (OP)
kys retard
Anonymous No.106501760
>>106501363
no
Anonymous No.106502639
>>106498514 (OP)
>linux systems
Anonymous No.106502651 >>106502732 >>106503472
>>106498514 (OP)
Macos security is a joke compared to Fedora Silverblue
Anonymous No.106502653
>>106498514 (OP)
Why would they? They don't have anything worth stealing.
The very rare and few that are... well, those billion-strong password server hacks every few weeks sure as hell aren't running Windows Server 2025.
Anonymous No.106502730
>>106498776
what random nonsense has he said?
Anonymous No.106502732
>>106502651
>FEDora
good joke
Anonymous No.106502740
>>106498514 (OP)
>jay
pottery
Anonymous No.106502917
During the time that PaX/Grsecurity was free software, Linux was secure.
(Pax/Grsec, Libsafe, bastille linux hardening script, GRADM)

Linus rejected in in 2008 for no reason.
Linus stopped everyone from suing them for copyright infringement in 2017 onward.
RMS too.

You can violate the GPL at will. No one will sue you. Ever.
Anonymous No.106503433 >>106508849
>>106498805
>Enabling IMA on a system is currently only recommended for development purposes.
>The default policies are unsuitable for general-use systems. The tcb policy opens up a local DoS where a malicious user can fill the measurement log and make the kernel run out of memory. The tcb_appraise policy prevents Portage from working.
kekkkkkkk
Anonymous No.106503472
>>106502651
>he doesn't know that on top of gatekeeper and SIP, the base system on macos is also immutable
freetard cope is embarrassing...
Anonymous No.106503526
>>106498890
Not an Itoddler myself, but the prism project was about cloud services and it not about scanning one's local files. Cellbrite can attack both android and ios devices, and there really isn't any systematic thing you can do about that. Apple actually made iphones reboot themself when they are not contacted with cellular network after some time, making it much harder for such device to compromise it, and most android vendors wouldn't even think about something like this.
Anonymous No.106503536 >>106503644
LITERAL Jay thread.
Anonymous No.106503644
>>106503536
LITERAL unmedicated post
Anonymous No.106504420 >>106504879 >>106504939
https://github.com/lkrg-org/lkrg
Anonymous No.106504879
>>106504420
kringe
Anonymous No.106504939
>>106504420
>While LKRG is bypassable by design, such bypasses tend to require more complicated and/or less reliable exploits.
lmao
Anonymous No.106504988
>As free LKRG becomes somewhat popular and possibly starts being deliberately bypassed by some exploits, we might introduce paid LKRG Pro as a means to fund the project and provide further diversity
you can't make this shit up
Anonymous No.106505077 >>106505498
>>106498514 (OP)
What's the malware risk to linux, installing unsigned packages in AUR? If you do that, you're just a retard
Anonymous No.106505498
>>106505077
linux is the malware
Anonymous No.106505515
locking the user out of full control of their hardware is cuckolding, not security
Anonymous No.106505519
>>106498514 (OP)
considering selinux makes it annoying to use my own goddamn machine at times: lol. lmao even.
Anonymous No.106506134
>>106498776
spwp
Anonymous No.106506181 >>106509946
>>106498514 (OP)
>Why don't linux systems protect themselves against malware?
Ok i'll bite: It does, you have a fuckload of tools at your disposal (conf hardening via partitioning, groups, kernel arguments and modules, policykit, dbus policies, firewall profiles, tomoyo/apparmor/selinux, firejail, third part demons like usbguard, etc...), just use them. Retard.
>inb4 i don't wanna configure shit!
All major distros and even lots of meme ones come out-of-the-box with such configurations.
Anonymous No.106506767 >>106507276
why is linux so gay?
Anonymous No.106507276
>>106506767
because
Anonymous No.106507432 >>106508021 >>106508080 >>106508484 >>106508547 >>106508849 >>106508888 >>106519298
>>106498805
Not nearly the same thing lmfao. MacOS "SIP" is also known as "rootless" mode, which is a much better name because it explains what it actually does. It restricts the root account to the point it can't do shit. Can't change system files, can't debug system processes, can't load/unload kernel extensions, can't use library preloading to code inject. The whole of /usr (and other system directories) becomes read-only permanently and there's no way to remount it as read/write while the OS is running. The only way to disable SIP is to reboot to recovery mode, to prevent someone from compromising root account and just disabling it.

Meanwhile on nearly every Linux distro, root can modify system directories like /bin and /usr, load arbitrary kernel modules, read/write kernel memory, or just kexec and replace the entire kernel. What a shitshow. No wonder no one takes that clown OS as a desktop seriously.
Anonymous No.106508021 >>106508557 >>106508593
>>106507432
retard take
Anonymous No.106508080 >>106508593
>>106507432
>when the root account is actually root
Anonymous No.106508484 >>106508593
>>106507432
That's actually good bait. Thank you for posting this, I was getting bored of low quality baits.
Anonymous No.106508516
>>106498514 (OP)
SELinux.
Anonymous No.106508547
>>106507432
>macos steals yo root
ftfy
Anonymous No.106508557
>>106508021
they literally think you're too retarded to be root on your own device. I'm not subjecting myself to such humiliation rituals
Anonymous No.106508593 >>106509750 >>106513224
>>106508021
>>106508080
>>106508484
All retarded, all of you.
Software freedom is important, being able to change the OS and software that runs on your computer is important. You can turn SIP off or boot Linux on a Mac if you want to.
But you don't need these permissions everyday. You don't need kexec ever. There is an extremely narrow usecase for kexec, live kernel updates, which is retarded and unstable anyway, because there's no way to pass state to the new kernel, so it assumes all hardware is uninitialized and so reinitializes it, completely dropping any state it had.
Freedom/convenience and security are on opposite ends of a spectrum. You can have something be completely free and convenient, but not secure at all (running everything as root on linux). Or you can have something be completely secure, but not at all free or convenient (in Linux this would be running in a container/VM as an unprivileged user with no permissions).

Oh and btw, before you mention sudo or similar, it's just security theatre. If I have access to your account, I can make a shell script in your PATH that echoes "[sudo] password for $USER", gets your password without echoing, then curls it somewhere and finally pipes it to sudo as a askpass program. I now have complete access to your system with your password and you'd be none the wiser.
This is why having an unprivileged account for SSH on servers is retarded and pointless, logging in as root is quicker and has equivalent security.

The only secure privilege escalation I'm aware of is the one in Windows, but you have to change UAC to prompt for all escalation to be secure. By default it doesn't prompt for system apps, which makes it security theatre since you can inject into explorer.exe and escalate with no prompt. But configured correctly, the escalation prompt is secure because it uses separate secure desktop where no other app can impersonate it. The "Administrator" account (logical equivalent of root) is also much more locked down.
Anonymous No.106508630
>>106498514 (OP)
>Security by obscurity
like macos?
>xitter screenshot
Anonymous No.106508849 >>106508888 >>106509002
>>106507432
Except that's exactly what IMA does too:
>Appraisal can be verified with ima_appraise=off and changing the contents of a root-owned file (or the value of the extended attribute) and reboot with ima_appraise=enforce, or by directly editing virtual guest images.
If you change the contents of a file it won't match the list of hashes in the TPM anymore and will therefore go ape shit.

As for restricting the root process in general, then that's nothing to do with integrity at all. That's more the purview of things like SELinux and AppArmor.

>>106503433
They have that warning because it doesn't work out-of-the-box. If you test it on your development machines and build an image with it enabled and verify that everything works then you can use it in production.

As far as I know, apart from Gentoo no distro is even supporting IMA.
Anonymous No.106508888 >>106509002
>>106508849
>>106507432
Also in regards to:
>Meanwhile on nearly every Linux distro, root can modify system directories like /bin and /usr, load arbitrary kernel modules, read/write kernel memory, or just kexec and replace the entire kernel. What a shitshow. No wonder no one takes that clown OS as a desktop seriously.

Use a read-only medium like a squashfs or erofs image if you don't want the base-system to ever be modified.
Kernel module signing has been standard for years now, so no, you can't load arbitrary unsigned kernel modules.
Kexec is prevented by kernel lockdown (except for validly signed kernels):
https://www.man7.org/linux/man-pages/man7/kernel_lockdown.7.html

There is nothing your toy macOS operating system does that Linux can't also do. It's had this stuff for years and years and years at this point. Do you think people running servers in data centers don't value trusted computing?
Anonymous No.106508940
>>106498514 (OP)
I don't believe you.
Anonymous No.106509002 >>106509094
>>106508849
>Except that's exactly what IMA does too
>As far as I know, apart from Gentoo no distro is even supporting IMA.
Do I even need to say anything

>>106508888
>read-only medium
But then how will the OS receive updates? Why do I have to choose between a fully read-only OS that never receives updates, and an "immutable" ostree OS, where the root user can still fuck around with the object store?
>kernel lockdown
Only enabled by default on UEFI secure boot, which most people disable for Linux. But it's a good measure nonetheless, on all my systems I have it enabled.
Btw it's also possible to lock kexec via sysctl (can't be reenabled until reboot), or in the extreme case recompiling with it disabled. But again neither of those are the defaults so not used by most people.
>people running servers in data centers don't value trusted computing?
They do, but their security model is much different. Google for example just builds its own server hardware for GCP, with its own Titan root of trust and custom software that runs on it, that fully controls the system from boot to shutdown. Meanwhile general consumer and server hardware is stuck with TPM2 as the most secure root of trust. (Although for servers, that may be changing in the future now that Oxide released Hubris for everyone to use, but it would still require new hardware to develop to run it)

You can absolutely make Linux more secure, with a lot of effort. But out of the box, macOS and Windows unironically "just work" and have far superior security with zero tinkering necessary:
>https://madaidans-insecurities.github.io/linux.html
And here's a guide I use from the same page to harden it:
>https://madaidans-insecurities.github.io/guides/linux-hardening.html

Oh and not to mention all Mac computers are full disk encrypted. When you "enable" FileVault/encryption, all it does is wrap the hardware encryption key with your password so it's instant. Meanwhile on Linux you have to reformat to enable LUKS.
Anonymous No.106509094 >>106509168
>>106509002
>But then how will the OS receive updates? Why do I have to choose between a fully read-only OS that never receives updates, and an "immutable" ostree OS, where the root user can still fuck around with the object store?
You update the image file. Also, ostree if implemented properly is also fully read-only at the filesystem level. Yes, you can fuck around with the object store but that's to facilitate updates (surprise: you need some sort of read-write access to update your operating system, even Apple requires that because you can't update fully in RAM, it's got to persist and be applied offline somehow)

>Oh and not to mention all Mac computers are full disk encrypted. When you "enable" FileVault/encryption, all it does is wrap the hardware encryption key with your password so it's instant. Meanwhile on Linux you have to reformat to enable LUKS.
Hardware encryption is compromised as fuck. LUKS does it right even if it's slower.
Anonymous No.106509168 >>106509204 >>106509206
>>106509094
>even Apple requires that
Apple OS'es don't write to system files to update when the OS is booted. Instead they stage the update files in the system partition, then reboot to the new XNU kernel image with a special kernel argument that allows the OS system files to be modified and loads a separate userspace path than the main OS path, which then performs the actual modification.
Before the introduction of SSV (macOS < 11), this would be like a regular mutable distro or Windows update. After SSV made its debut in macOS 11, this doesn't replace the system files in place, but instead writes them to a new APFS snapshot. When the update is complete, the OS then reboots and uses the new snapshot as the root for system files, with the old snapshot then removed. Of course it would be trivial to add rollback to this, but Apple makes perfect code so rollback is not needed /s

>Hardware encryption is compromised as fuck. LUKS does it right even if it's slower.
It's the same encryption math either way. LUKS encrypts your entire system but with SSV FileVault only encrypts the data subvolume. And having all Macs encrypted by default using hardware keys is good for normies even if it's not secure. Real users just enable FileVault (and don't make the mistake of escrowing your recovery key to iCloud), then they get same security as LUKS as it will require the password on boot.
Apple put a lot of effort in separating system from data, the FileVault unlock screen used to be an EFI application (back when even the kernel was encrypted on the main drive), but now is a fully hardware accelerated graphical environment where 70% of the userspace is already loaded, complete with Bluetooth for wireless peripherals. Compare that with Linux where the Plymouth password prompt is as fancy as you will get before your data is unlocked, as it's constrained by the initrd.
Anonymous No.106509204
>>106509168
Didn't realize macOS was that far ahead of the game. Sheesh
Anonymous No.106509206 >>106509250
>>106509168
>Apple OS'es don't write to system files to update when the OS is booted. Instead they stage the update files in the system partition,
You can implement exactly the same system under Linux though. In fact many distros do do offline updates today in a similar manner (only they're staging it somewhere on the OS partition but this is a moot point). If you want to implement something similar to Apple yourself, for example, staging a new squashfs or erofs image and then applying it at reboot, then you can.

As for their encryption being technically worse but more normie friendly, I'd agree that's a good thing. A lot of Linux distros will setup LUKS for you in the installer nowadays though if you want that.
Anonymous No.106509239 >>106509268
>>106498514 (OP)
>Why don't linux systems protect themselves against malware?
Because Linus rejected PaX/Grsecurity in 2008 for no reason.

Then Grsecurity decided to violate the GPL in 2017-ongoing (of both GCC and Linux) because they had the backing of the US Army. Who will just seize whatever Linux Kernel related patents exist under the The Invention Secrecy Act of 1951 if Linux retaliates in a lawsuit. This is enough of a threat to keep any possibility of such at bay.

>NOOO LINUX DOESNT HAVE ANY PATENTS
Yes "it" does, which is the whole reason "it" didn't go to GPLv3: to avoid forced patent agreements.
Anonymous No.106509250
>>106509206
Also, it's important to note that Linux does support inferior hardware encryption if you really want that:
https://wiki.archlinux.org/title/Self-encrypting_drives

The only issue with it (besides it being compromised as fuck) is that Linux distros don't control what hardware you use like Apple does, so it would be very difficult to enable this inferior scheme by default.
Anonymous No.106509268 >>106509395 >>106509420
>>106509239
Linux can't even sue them in the first place, what they're doing is absolutely disgusting but perfectly compatible with the GPL2.
Anonymous No.106509395 >>106509471
>>106509268
>Linux can't even sue them in the first place,
Yes they can, you can ALWAYS sue.
>what they're doing is absolutely disgusting
correct.
> but perfectly compatible with the GPL2.
Wrong.

Stop claiming this.
The copyright owner has the right to control derivative works.
Linus and all the rest of the copyright holders of linux want changes to be redistributed.
Grsecurity never paid linus or anyone else anything.
Linus and everyone else can rescind GRsecurity's permission to use linux to make derivative works at _ANY_ time.

Yes this would cause a copyright exploratory suit. No Grsecurity wouldn't win it.
Yes it would cost "Linux" 1 million dollars to go through the courts with it.

2): Grsecurity is also violating article 2 section 6 of the GPLv2. Which is, in and of itself, a copyright violation.

Linus and the rest can go after them for that. In their "access agreement" they make the "subscriber" promise not to redistribute the derivative work.

This is a restriction placed on the "subscriber" that is not present in the GPL, and is also at cross-purpouses to both the GPL and the intention of Linus and the linux copyright holders in their use of the GPL as their license memorandum:
They made clear they wanted all changes to return to them.

On video, everywhere.
Anonymous No.106509420 >>106509471
>>106509268
> is grsecurity violating the linux and GCC copyrights

While it hasn't been definitively proven in court, there is a strong legal argument that Grsecurity's commercial practices violate the GNU General Public License (GPL) version 2, which governs the Linux kernel. The core of the controversy lies in their "Stable Patch Access Agreement" and whether it adds restrictions prohibited by the GPL.
Anonymous No.106509471 >>106509528
>>106509395
>>106509420
GRsecurity isn't violating the GPL though. Nothing about the GPL requires you to give patches to anyone and everyone. They only require that you produce the source to anyone whom you yourself distribute the software to (and require them to do the same).

A subscriber promise is a business contract with them, you're right this isn't present in the GPL which means the GPL still takes precedence. GRSecurity can terminate you as a customer but they cannot stop you from distributing their patches. Anyone who took them to court would probably lose because of that, the court would rule in favour of GRSecurity that they're allowed to choose who they do business with and how they do that, but at the same time they're not allowed to re-write the GPL (which is why they don't do that. Their business contract is a separate agreement)
Anonymous No.106509477 >>106509482
>>106498514 (OP)
Linux users are broke and jobless so there's no incentive to make wise spread malware
Anonymous No.106509482 >>106509582
>>106509477
Almost every multi-billion dollar company on the planet runs Linux in some capacity.
Anonymous No.106509528 >>106509534 >>106519952
>>106509471
>GRsecurity isn't violating the GPL though. Nothing about the GPL requires you to give patches to anyone and everyone. They only require that you produce the source to anyone whom you yourself distribute the software to (and require them to do the same).

Yes they are.
Article 2 section 6 of the GPLv2 states that the distributor of a derivative work may not impose any furthur restrictions on the redistribution of the affected work.

Grsecurity adds a restriction: that if a person redistributes the derivative work: they lose money.

A court would understand what the GPL is about, and that GRsecurity is violating it.

>but at the same time they're not allowed to re-write the GPL
You're an idiot: and I'll kill you if I meet you:
The GPL is not protecting "itself" from being "rewritten" in Article 2 section 6.

It is govorning the relationship between the derivative-work distributor, and the distributee:
it says that the distributor of a derivative work may not impose hardships on the distributee beyond that which is in the text of the memorandum of the original work's license to the distributor.

It is not saying "u can't change the text of the GPL!". Copyright law allready does that. Grsecurity has no right to modify the FSF's license work-product called the GPL at all.

The GPL says that you can modify Linux; but if you frustrate the distributee's ability to do what you have done: then your license is canceled.

Which is what Grsecurity has done.

>(which is why they don't do that. Their business contract is a separate agreement)
That does not matter: the GPL governs that "seperate agreement": as it is pertaining to the corpus of the copywritten work: Linux (and GCC).

Grsecurity has no right to make contracts with other people, regarding it's derivative work of the Linus Kernel and GCC: the Copyright office says the original copyright holder _CONTROLS_ derivative works.

Not Grsecurity. Not down-the line programmers.
Again: I'll kill you straight dead.
Anonymous No.106509534 >>106509545 >>106509557 >>106512421
>>106509528
>Article 2 section 6 of the GPLv2 states that the distributor of a derivative work may not impose any furthur restrictions on the redistribution of the affected work.
>
>Grsecurity adds a restriction: that if a person redistributes the derivative work: they lose money.
A contractual obligation is not the same as adding a restriction to the GPL. It affects your access to them as a business, not your access to the code you already have and your ability to redistribute that.
Anonymous No.106509545 >>106509554
>>106509534
As I said: I will kill you straight dead.
Anonymous No.106509554 >>106509575 >>106512421
>>106509545
Maybe learn the difference between a business contract and a software license agreement first.
Nobody is stopping you from re-distributing GRsecurity's GPL2 code. The only thing stopping you is the fact that they'll terminate your business relationship with them if they find out and that is extremely scummy but perfectly within their rights to do.
Anonymous No.106509557 >>106509569
>>106509534
The GPL governs the contracts between Grsecurity and Distributees. Because Grsecurity is a non-seperable derivative of Linux (and GCC).

I will kill you if I meet you, dipshit.
Grsecurity does not have an independent right to edit Linux and GCC, outside of fair-use.
Thus they do not have an independent right to make whatever contracts they want to.
Anonymous No.106509569 >>106509575 >>106509591 >>106512421
>>106509557
A business can make whatever contracts with you as a customer as they want. The GPL cannot dictate how a company does business with you nor does it attempt to do so. It governs the software being distributed and there you're not losing any rights whatsoever.
Anonymous No.106509574
>>106498514 (OP)
SELinux, AppArmor, and Flatpaks.
Anonymous No.106509575 >>106509587
>>106509554
Hey dipshit fuck, I'm a lawyer: you are not.
I _WILL_ kill you if I meet you.

Grsecurity is not an independent work.
It is a non-seperable derivative of Linux, and of GCC.
That means it has to obey the rules Linus and RMS set forth or it has no right to exist at all.

That means they CANNOT make buisness contracts that frustrate the purpouse of the copyright license they have been given for free.

Yet they do.
>>106509569
>A business can make whatever contracts with you as a customer as they want.
NO THEY CANNOT.
These contracts MUST obey copyright law, DIPSHIT FUCK. They must obey FEDERAL LAW: DIP FUCKING SHIT FUCK

__ALL__ OF FEDERAL LAW
DIP FUCKING __SHIT__

>I am doing a biz contract, so I only have to follow biz law!
NOPE DIP FUCKING _SHIT_
Anonymous No.106509582
>>106509482
K
Anonymous No.106509587 >>106509606 >>106509694 >>106512421
>>106509575
Are you now? Where do you practice? You should be reported to the bar for spreading this fud.

A business contract doesn't have to obey copyright law because that's not what it governs. It governs their relationship with them (a business) and you (a customer). It has nothing to do with GPL (or non-GPL) software at all. It's a customer agreement that you as a customer willingly enter into.
Anonymous No.106509591 >>106509603
>>106509569
>A business can make whatever contracts with you as a customer as they want.
No they cannot.

>The GPL cannot dictate how a company does business with you
Yes it can.
>nor does it attempt to do so.
Yes it does.

From Copyright (creation, derivatives, distribution, performance), to Patents (GPLv3) the GPL does exactly that: require cross-patent licensing agreements.

> It governs the software being distributed and there you're not losing any rights whatsoever.
Wrong. It is bare permission from Linus and RMS etc to random free-takers like Grsecurity. Nothing more.
It says what permissions are given.
All the rest are withheld.

Grsecurity is not permitted to create a buisness agreement that frustrates the purpouse of the Copyright license it relies on to create it's non-seperable derivative work.
Anonymous No.106509603 >>106509623 >>106509628
>>106509591
With that logic Red Hat is not permitted to create a business agreement to sell RHEL to its customers.

You're a fucking retard. You still haven't answered where you practice law. I get that you're anonymous here but maybe backup your credentials if you're going to pull the "actually, I'm a lawyer" card.
Anonymous No.106509606 >>106509627
>>106509587
>Are you now?
Yes
>Where do you practice?
New York.
> You should be reported to the bar for spreading this fud.
You going to do it.
>
>A business contract doesn't have to obey copyright law
Yes it does.
A business contract has to obey all federal and state statutes, and judicial decisions.

>because that's not what it governs.
A business contract has to obey all federal and state statutes, and judicial decisions.

>It governs their relationship with them (a business) and you (a customer).
A business contract has to obey all federal and state statutes, and judicial decisions.

> It has nothing to do with GPL (or non-GPL) software at all.
A business contract has to obey all federal and state statutes, and judicial decisions.
> It's a customer agreement that you as a customer willingly enter into.
A business contract has to obey all federal and state statutes, and judicial decisions.

You going to report me to the bar now?
I will kill you btw.
Just letting you know.
Anonymous No.106509623 >>106509627
>>106509603
>>With that logic Red Hat is not permitted to create a business agreement to sell RHEL to its customers.
Red Hat owns over 50 percent of the linux kernel source code.
The linux kernel is likely a Joint Work.
A copyright owner in a Joint Work can license the Joint Work out to anyone however it wishes: regardless of the wishes of the other contributors to the Joint Work.
That's copyright law 101.

>
>You're a fucking retard.
You're the one that said one does not have to obey state and federal law when making business contracts.
Guess I can have contract killings: it's a buisness contract: federal law "doesn't apply" (your logic)
>You still haven't answered where you practice law.
New York.

>I get that you're anonymous here but maybe backup your credentials if you're going to pull the "actually, I'm a lawyer" card.
I am a lawyer.
Dialing up the Bar to report me yet?
Anonymous No.106509627 >>106509661 >>106509725 >>106509852
>>106509606
>>106509623
Where specifically in New York? Which legal practice?

You do realise that a separate contract that stipulates that they'll terminate their relationship with you if you breach its terms is fully within the federal and state statutes.

A business has the right to terminate you as a customer. The GPL cannot force a business entity to provide their services to you.
Anonymous No.106509628 >>106509635
>>106509603
Grsecurity is not a contributor to the linux kernel (Linus rejected their work), and is not a participant in the Joint Work that the Linux kernel is.

That's why Red Hat can do it.
And Grsecurity cannot.
Copyright law 101.
Anonymous No.106509635 >>106509669 >>106509684
>>106509628
That's not in fact how the GPL works. Anyone can sell it.
Anonymous No.106509661
>>106509627
>Where specifically in New York?
Brooklyn
> Which legal practice?
Not going to tell you
>
>You do realise that a separate contract that stipulates that they'll terminate their relationship with you if you breach its terms is fully within the federal and state statutes.
Violating copyright law is not fully within the federal statutes.
>
>A business has the right to terminate you as a customer. The GPL cannot force a business entity to provide their services to you.
Yes it can.
The Linux License could , if Linus et all wished it, stipulate that "you must provide anti-hack services for 1000 years to everyone, like a dog or a slave, or else you don't have a license to make derivative works of the Linux kernel". And then if you
1) made derivative works
and
2) didn't provide anti-hack services for (some amount of time*)
Linus et all could immediately sue for copyright infringement, and recover.
That is if they ever bothered to register their copyrights at all (they haven't).
(so no attorneys fees nor statutory damages are available to them)

*(Rule against perpetuity would likely stop this insane copyright license contract from reaching beyond 80 or so years, (also probably beyond the 30 year clawback provision in the federal copyright statute))


In the same vein;
The GPL can prevent you from prevailing on a claim of non-copyright infringement
"because my behavior is in line with the buisness agreement I have with someone else"
where that buisness agreement frustrates the purpose of the original copyright holders reason to give you a copyright license to begin with.

The reason linus gave out these copyright licenses was made clear by him: on video: and in emails: he said he wants _ALL_ contributions to come back to him.
That is why he attached the GPL memorandum to his copyrighted work.
It's a 1 page document, not completely integrated, this information would be noted by the courts.
Anonymous No.106509669
>>106509635
It IS how copyright law works.
No: Grsecurity cannot violate the GPL and sell it under some other agreement (but it does so anyway)
RedHat: being a copyright owner in the Joint Work that is the Linux Kernel: CAN license it out however it wishes.

Grsecurity is not in that position.
RedHat is.
Anonymous No.106509684
>>106509635
You're just wrong. The GPL even has price-discrimination stipulations in it: saying you can't sell the source code for more than a "reasonable fee". Go read it, idiot.

>A business has the right to terminate you as a customer.
Not when the purpose of that termination is to frustrate the purpose of the extension of the copyright license to the licensee to begin with: which is that the original copyright owner has access to the source code of all changes (Linus stated this again and again: HE is the copyright owner: not "the GPL").
Anonymous No.106509694
>>106509587
>>A business contract doesn't have to obey copyright law
Yes it does.
Anonymous No.106509725
>>106509627
>A business has the right to terminate you as a customer.
When that is a punishment for redistributing the derivative work;
no it does not have that right.

> The GPL cannot force a business entity to provide their services to you.
The Copyright owner can end your permission to use his work as a basis for your business
1) Whenever he feels like it if you didn't pay him what he asked, even if he gave it "for free".
2) If you did pay: When you do not adhere to a stipulation attached to a revocation clause .

Here
1) Grsecurity didn't pay.
So their license can be ended at will.
and
2) Even if Grsecurity did pay Linus et all for a copyright license contract
And in that case then could only be terminated for cause within the license contract:

Grsecurity, knowing that it's buisness would be impacted should it's source code be distributed :
has taken measures against those who do distribute it's source code;
since that source code is a non-seperable derivative of Linux (and GCC)
the revocation clause in the GPLv2 applies even with a paid-for contract between Linus and Grsecurity (note: which doesn't actually exist)

And their license can be revoked for cause: adding restrictions to redisribution of the derivative work.
Anonymous No.106509750
>>106508593
>But you don't need these permissions everyday. You don't need kexec ever.
ok.. so don't use it
>If I have access to your account, I can make a shell script
sudo does not protect root authority from someone who has access to your account. that's not one of the things it does, so why are you telling us this story like it somehow highlights one of its weaknesses?
Anonymous No.106509782
Hey, you gunna disbar me?
I said contracts have to follow federal law, including copyright law.

That's a disbarrable offence right?
Right patel?

You calling up the hotline?

Right you fucking Jeet piece of shit.
Ringing the phone number
1800-Disbar-Me?
Anonymous No.106509787
Hey, you gunna disbar me?
I said contracts have to follow federal law, including copyright law.

That's a disbarrable offence right?
Right patel?

You calling up the hotline?

>Brahmin's don't need to obey federal laws! They can make whatever buisness contracts they want

You ringing it up?
Anonymous No.106509793
Hey, you gunna disbar me?
I said contracts have to follow federal law, including copyright law.

That's a disbarrable offence right?
Right patel?
Anonymous No.106509852
>>106509627
>Which legal practice?
He has already admitted to being a NEET that lives in his mother's basement.
Anonymous No.106509946 >>106517763
>>106506181
all garbage. linux lost.
Anonymous No.106511455
>>106498514 (OP)
do it yourself
Anonymous No.106512421 >>106513138
>>106509534
>>106509554
>>106509569
>>106509587
You are a dumb nigger spewing sewage

And to the schizo: you are a retard to still think that the commie cuck himself will ever do anything unless he personally benefits from it. He told you that he licks for scraps at his master's feet two fucking decades ago, retard.
Anonymous No.106513138 >>106513147
>>106512421
>>>/pol/
Anonymous No.106513147
>>106513138
>>>/lgbt/
Anonymous No.106513224 >>106514537
>>106508593
Hmmm that's actually interesting.
>The only secure privilege escalation I'm aware of is the one in Windows, but you have to change UAC to prompt for all escalation to be secure.
How does this work?
Does this also prevent the escalations that can occur from elevating via registry edits?
Anonymous No.106513787
>>106498890
yes
Anonymous No.106514537 >>106514835
>>106513224
>How does this work?
Windows has native support for multiple desktops (not "virtual desktops" but rather more "fast user switching" desktops, aka sessions). All user applications run in the user's own desktop, but the LogonUI (lock screen), Ctrl+Alt+Delete menu, and (optionally) the elevation prompt, all run in a separate desktop called the "Winlogon secure desktop".
Pressing Ctrl+Alt+Delete is always a forced switch to the secure desktop. No application can override it, only a few select applications can emulate it (such as onscreen keyboard). This is why in enterprise settings, pressing it is required before logon, as it's a hard filter for any app that tries to mimic system credential prompts. By training users to always press and expect Ctrl+Alt+Delete before entering credentials, the hope is they immediately will be suspicious when it's not required. I don't know how effective it is in practice though.
The secure desktop runs in a completely different context, as a separate winlogon system user. When something requires the it, winlogon will pull you into it, kind of like a fast user switch (except every user has their own separate winlogon desktop). Then you interact with the menu, or enter your password to unlock, or enter admin credentials to elevate, and then it will pull you back into your main desktop.
>Does this also prevent the escalations that can occur from elevating via registry edits?
If configured to always prompt, it will require admin elevation before accessing the registry, or any other system app. By default, elevation from system apps is silently allowed (if you have permissions) (because people complained Vista had too many prompts), so it's possible to trivially exploit it by starting and injecting into a trusted system process to then elevate. But in UAC settings you can change it to "always prompt" and that will make it actually secure.
See here for more info:
>https://devblogs.microsoft.com/oldnewthing/20160816-00/?p=94105
Anonymous No.106514835 >>106515397
>>106514537
Okay, but it was my understanding that most of the elevation techniques for UAC still work even with UAC configured to the highest setting.
https://github.com/hfiref0x/UACME

What are your thoughts on the new Windows 11 'Administrator Protection' feature that seems conceptually very similar to UAC, but is implemented differently under the hood?
Anonymous No.106515397
>>106514835
>https://github.com/hfiref0x/UACME
From what I understand this basically relies on abusing autoelevated components like some EXE's or COM objects, and getting them to run arbitrary code, in the former case by making them load a DLL, in the latter by changing registry parameters in the current user profile to get them to run a command or load code. So it's not really a "UAC bypass" in the sense that it somehow tricks UAC, rather it abuses already elevated (or autoelevated) components without triggering UAC at all. I would call it a "privilege escalation" not a "UAC bypass".
It's kind of out of scope of UAC, in the same way you can harden sudo as much as you want, but if you have sshd allowing anyone to login as root without a password then it won't really help you.
>Windows 11 'Administrator Protection' feature
Haven't heard of it until now but looks promising. Basically it looks to me like branding for a bunch of smaller things, most importantly it removes autoelevation from all Windows components which should hopefully kill off those "UAC bypasses" (really privilege escalation exploits). The windows hello integration is cool I guess, although I don't use it. And the profile separation is really nice as well, it should stop escalated programs from being coerced into running arbitrary code through registry or DLL hijacks since it's in a clean environment. So it's not really replacing UAC but rather mitigating security exploits that avoid UAC by exploiting an already elevated (so already cleared and approved by UAC) process.
Anonymous No.106515569 >>106517546 >>106520028
leunuchs lost
https://www.youtube.com/watch?v=OXS8ljif9b8
Anonymous No.106516712
filtered
Anonymous No.106517546
>>106515569
DILATE THIS
Anonymous No.106517763
>>106509946
not an argument
Anonymous No.106518262
>>106498805
>It's like he knows absolutely nothing about Linux.
and that's a good thing
Anonymous No.106519270
>>106498514 (OP)
fpbp
Anonymous No.106519298
>>106507432
So you don't understand user permission hierarchy, got it.
You're like a retard guitarist. "Just turn it up to 11! It's one louder!"
Anonymous No.106519428 >>106519813
i dont get it
Anonymous No.106519813
>>106519428
i dont get it
Anonymous No.106519952
>>106509528
>You're an idiot: and I'll kill you if I meet you:
i liked you better when you were just going on and on about your casino game and Deuteronomy and little girls, Mikee
Anonymous No.106520028
>>106515569
>2013
Kek, even freebsd implemented "le mitigations" since (see hardened freebsd), also linux distros as well.