Warning! Linux Security. Are You at Risk?

khess 0 463 Views

I'm not talking about openssl, PHP, or even the Linux kernel but all the above plus every other program or bit of code on a Linux system. It's vulnerable. It's hackable. It can be changed at will by anyone because the source is open and freely available (the definition of open source).

Windows code, on the other hand, is not open and available, therefore it's much safer.

Do you believe that open source programs are more vulnerable because their code is available, visible and accessible? Do you believe that the Windows operating system and Windows applications are more secure because the code isn't available to you and potential hackers?

You'd be right if you believe the first and wrong if you believe the second of those questions. Why?

While it's true that allowing someone to view your code, leaves it somewhat more vulnerable than if it were hidden--it is not true that hidden code is more secure. So, if it's more vulnerable, why all the hype about Linux and open source and why does anyone think it's better?

Because Linux is more secure. Say what???

It works like this: If your code is visible, hackers, crackers, and annoying tweakers can get in and perhaps find a security vulnerability and exploit it. It's also visible to the good guys who can fix those vulnerabilities--in fact, by the time you hear of a security vulnerability in the open source world, someone has already fixed it and posted the patch for all to download and use--many repositories pick up the fixes so that they can be installed automatically.

Alternatively, Windows vulnerabilities are often exploited worldwide at the cost of hours and hours of time, disrupted business, stolen credit card info, and compromise of critical data and systems. By the time a fix is available, the damage is done.

Ask anyone from the 2008 Black Hat Hacker's Conference where Mac OS X was hacked first, then Vista but Linux withstood all and emerged as the only OS that was not hacked.

Are you at risk? Yes, everyone is, but you're safer with Linux than with any other operating system. Keep that system up to date with yum, apt-get, smart or other automatic download, install and patch tools and sleep better at night.

Dani AI

Generated

A short, practical correction to the premise: open source visibility is not the same as automatic insecurity, nor is secrecy a substitute for good engineering. Public code makes bugs discoverable (the famous “given enough eyeballs” idea from Eric Raymond), but defenders only win if they treat discovery as a process — inventory, test, patch, and monitor. Assume attackers can learn your stack (Kerckhoffs’ principle) and build controls accordingly. The Cathedral and the Bazaar. (en.wikipedia.org) Kerckhoffs' principle. (en.wikipedia.org)

Actionable checklist (prioritise what matches your environment):

  • Make patching a program: inventory, staging, fast emergency fixes, and a rollback plan. Follow NIST’s guidance when you only have minutes to act. NIST SP 800-40 Rev.4. (csrc.nist.gov)
  • Harden to a baseline: use vendor or community benchmarks (CIS) and automate regular compliance scans. CIS Benchmarks. (cisecurity.org)
  • Enforce mandatory access controls: enable SELinux/AppArmor and keep them in enforcing mode where supported. Test policies before production. SELinux getting started (Fedora). (docs.fedoraproject.org)
  • Lock down services (minimal install, firewall, SSH keys only, PermitRootLogin no, rate‑limit logins), run file-integrity and audit tooling, and monitor logs/alerts. See sshd_config docs for authoritative options. (man.openbsd.org)
  • Treat supply-chain trust as part of security: prefer signed packages, official repositories and follow OpenSSF guidance for project hygiene. (baseline.openssf.org)

Example (Debian/Ubuntu + RHEL checks):

# Debian/Ubuntu: enable automatic security installs
sudo apt update
sudo apt install -y unattended-upgrades
sudo dpkg-reconfigure --priority=low unattended-upgrades

# Verify SELinux state (RHEL/Fedora)
getenforce
sestatus

(See Ubuntu automatic-updates docs for config details). (documentation.ubuntu.com)

As noted, vendor/distributor curation matters — pick maintained distros, subscribe to their advisories, and bake patch/testing into ops. Open source helps when the community and maintainers actively operate that feedback loop; otherwise visibility without maintenance is a real risk.

Member Avatar for Rashakil Fol
Rashakil Fol 978 Super Senior Demiposter

Duh.

Member Avatar for NZheretic
NZheretic 0 Newbie Poster

http://itheresies.blogspot.com/2005_04_01_archive.html

Monday, April 11, 2005
Core, maintaining reputation and license to fork

The major commercial Linux distributions ( such as Redhat, Suze, Mandrake etc ) and bundling vendors ( such as openlogic's blueglue ) maintain a large number of open source software packages as part of their core products. The reputation each of these distributions is entirely dependent upon the quality and security of each component. All of the vendors apply patches to the software before compiling, so effectively they maintain the included packages for you. You can depend on the vendors desire to maintain their reputation to use the open source software they distribute.

The difference with pure proprietary software is that either through a desire to do the right thing or because of the terms of the license, changes made by the vendors get distributed back to the open source software project developers. If you see that the original developers are including patches from the vendors or applying their own solutions to fix the same issues in a timely manner, then you can expect to trust that software project independent of the vendor platform.

To a lesser extent, the same dynamics of reputation apply to "community" Linux distributions ( Debian, Gentoo ) and vendor "development" distributions ( Fedora ).

At some point some open source projects developers may go in a direction that the distribution vendors and end uses may disagree with. It is the licensing which allows a fork of the project to develop that sets the open source development model apart from the pure proprietary development model. Apache, X.org and even the current version of the GNU GCC compiler toolset have been all derived from an outside fork of an existing open source project. No vendor or open source software developer can block development for any substantial period of time without the risk of the development being taken over by a descendant of the same project -- it's called evolution.

Any so called analyst or even a journalist who covers open source software, that cannot grasp the above simple concepts must be lacking in either competence or integrity.

- republish at will

Member Avatar for khess
khess 95 Practically a Master Poster

Thanks. That is an informative and useful post. I appreciate it.

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.

Edit Preview