|
|
Home | Switchboard | Unix Administration | Red Hat | TCP/IP Networks | Neoliberalism | Toxic Managers |
| (slightly skeptical) Educational society promoting "Back to basics" movement against IT overcomplexity and bastardization of classic Unix | |||||||
Enterprise Unix Administration /Advanced Linux Administration /Red Hat Administration
|
|
Generally we can classify security measures into two broad categories.
|
|
Of course the distinctions are sometimes fuzzy as changing some static configuration settings, for example enabling TCP wrappers lead to introduction of dynamic processes.
There are at least two dozens of broad categories for typical security enhancing measures:
Telnet security
Warnings, log and accounting issues
Ennbling accounting and using accounting data
Baselines
Applications security
Mail server security
Database issues
The key components of OS security are analyzed feature by feature and then presented in integrated form with the corresponding numerical scores in the comparative security matrix.
Linux patching process quality is noticeably worse then on Solaris and access to patches requires maintenance contact. Patches are distributed as updated packages and may involve updating the version of the software although enterprise Linux distributions like Red Hat and Suse are trying to do necessary work to avoid that.
According the U.S. Government’s database of computer security vulnerabilities maintained by the National Institute of Standards and Technology (http://icat.nist.gov) as of April 15, 2004, there have been more High Severity (remotely exploitable) vulnerabilities found in the Linux operating system than in Microsoft Windows. This count removes duplicate reports of the same vulnerability against multiple versions of Linux or Windows. The CERT report claims that security alerts for open source and Linux software accounted for 16 out of the 29 advisories published during the first 10 months of 2002. During those same 10 months, only seven security problems were documented in Microsoft products. NewsFactor Network - - Study Linux' Security Problems Outstrip Microsoft's
An analysis of hacker attacks on online servers in January by security consultancy mi2g found that Linux servers were the most frequently rooted, accounting for 13,654 successful attacks, or 80%t of the survey total. Windows ran a distant second with 2,005 attacks. A more specific analysis of government servers also found Linux more susceptible, accounting for 57% of all breaches. In a similar analysis last year, Windows proved far more vulnerable, with 51% of successful attacks on government servers made on some version of the Microsoft operating system.
However, the rise in successful attacks probably to a large extent reflects a lack of training and deployment expertise rather than inherent security problems in Linux.
Linux currently does not have process protection/virtualization capabilities that are equivalent to Solaris zones or AIX partitions. There are some attempts to replicate the capabilities of BSD jails but they are still in beta.
The number of books devote to Linux security is considerable and by an order of magnitude surpass the number of Solaris books. Red Hat offers four security-related training courses (approximately the same as Sun for Solaris). We judge that in area Linux surpass all other Unixes and trails only Windows.
Most security certification specialists consider Linux less secure that top proprietary Unixes (AIX and Solaris) and that requires running Linux in a special way to augment security (deeper hardening) to compensate for this.
Many people are under the misconception that since Linux has been evaluated under the Common Criteria for IT Security Evaluation (ISO Standard 15408) that Linux must be secure. But here are the facts: Linux has been certified to EAL 3+ and EAL 4 under the Common Criteria. Those are pretty basic certification that tells not much about real-world level of security of the OS. By comparison, Windows has been also certified to EAL 4. Both AIX and Trusted Solaris are capable reaching EAL 7 certification.
The Common Criteria standard states: “EAL 4 is the highest level at which it is likely to be economically feasible to retrofit an
existing product line.” This means that if a product was not originally designed for security, it will probably never exceed EAL 4.
And as we all know Security was not a focus of the original design of Linux.
Another widespread misconception that the NSA is going to solve Linux’s security problems with its Security Enhanced Linux (SELinux).
But this is an urban legend. Here are a few excerpts (http://www.nsa.gov/selinux/info/faq.cfm):
Another security problem is created by the GNU General Public License (GPL) under which Linux is licensed. GPL Section 2b (emphasis added):
“You must cause any work that you distribute or publish, that in whole or in part contains or is derived from [Linux] or any part thereof, to be licensed as a whole at no charge to all third parties under the terms of this License.”
That is both a legal problem (due to SCO lawsuit and potential patent-infringement lawsuits) and a cultural problem that can be classified as an implicit threat to the security of any software-based intellectual property developed on Linux. It is recommended to acquire Linux only from the vendors that provide indemnification against legal threats.
Linux run on two types of hardware Classic Intel x86 architecture and EM64T-based CPUs (Intel Nocona or AMD Opteron). EMT64T is a 64 bit extension of classic Intel architecture by AMD also adopted by Intel. Generally hardware cost is the most important potential saving factor in deploying Linux and Opteron architecture is slightly more expensive. But is also slightly more secure, as if the operating system is configured to operate in 64 bit mode it is less susceptible to 32-bit oriented exploits. The latter represent about 90% of all exploits (hackers really test their code on 64 bit systems).
32 bit Intel hardware is the most hacked hardware in existence and is widely available to hackers of any country on the globe. By just switching to 64-bit hardware we can somewhat decrease security risks. The most damaging Linux virus so far, the Slapper worm, infected 20,000 systems in 100 countries in late 2002. That pales in comparison to the most damaging Windows virus, MyDoom and its variants, which infected several million computers in three weeks. But there are orders-of-magnitude more Windows machines deployed.
By just switching to 64-bit hardware we can somewhat decrease hardware-related security risks.
|
|
Switchboard | ||||
| Latest | |||||
| Past week | |||||
| Past month | |||||
 |
 |
 |
Oct 14, 2018 | linux.slashdot.org
Reverend Green ( 4973045 ) , Monday December 11, 2017 @04:48AM ( #55714431 )Re: Does systemd make ... ( Score: 5 , Funny)Systemd is nothing but a thinly-veiled plot by Vladimir Putin and Beyonce to import illegal German Nazi immigrants over the border from Mexico who will then corner the market in kimchi and implement Sharia law!!!
Anonymous Coward , Monday December 11, 2017 @01:38AM ( #55714015 )Re:It violates fundamental Unix principles ( Score: 4 , Funny)The Emacs of the 2010s.
DontBeAMoran ( 4843879 ) , Monday December 11, 2017 @01:57AM ( #55714059 )serviscope_minor ( 664417 ) , Monday December 11, 2017 @04:47AM ( #55714427 ) JournalRe:It violates fundamental Unix principles ( Score: 5 , Funny)We are systemd. Lower your memory locks and surrender your processes. We will add your calls and code distinctiveness to our own. Your functions will adapt to service us. Resistance is futile.
Re:It violates fundamental Unix principles ( Score: 4 , Insightful)I think we should call systemd the Master Control Program since it seems to like making other programs functions its own.
Anonymous Coward , Monday December 11, 2017 @01:47AM ( #55714035 )Don't go hating on systemd ( Score: 5 , Funny)RHEL7 is a fine OS, the only thing it's missing is a really good init system.
|
|
|
Jan 26, 2019 | blog.erratasec.com
John Morris said...
They don't want to replace the kernel, they are more than happy to leverage Linus's good work on what they see as a collection of device drivers. No, they want to replace the GNU/X in the traditional Linux/GNU/X arrangement. All of the command line tools, up to and including bash are to go, replaced with the more Windows like tools most of the systemd developers grew up on, while X and the desktop environments all get rubbished for Wayland and GNOME3.And I would wish them luck, the world could use more diversity in operating systems. So long as they stayed the hell over at RedHat and did their grand experiment and I could still find a Linux/GNU/X distribution to run. But they had to be borg and insist that all must bend the knee and to that I say HELL NO!
|
|
|
Jan 26, 2019 | blog.erratasec.com
Siegfried Kiermayer said...
I'm waiting for pulse audio being included in systemd to have proper a boot sound :D
|
|
|
Aug 30, 2015 | www.agwa.name
This is the core system within systemd that allows different bits of userspace to talk to each other. But it's got problems. A demonstration of the D-Bus problem is the recent Jeep hack by researchers Charlie Miller and Chris Valasek. The root problem was that D-Bus was openly (without authentication) accessible from the Internet.
Likewise, the "AllJoyn" system for the "Internet of Things" opens up D-Bus on the home network. D-Bus indeed simplifies communication within userspace, but its philosophy is to put all your eggs in one basket, then drop the basket.
|
|
|
Oct 02, 2016 | www.agwa.name
Systemd maintainer David Strauss has published a response to my blog post about systemd . The first part of his post is replete with ad hominem fallacies, strawmen, and factual errors. Ironically, in the same breath that he attacks me for not understanding the issues around threads and umasks, he betrays an ignorance of how the very project which he works on uses threads and umasks . This doesn't deserve a response beyond what I've called out on Twitter.
In the second part of his blog post, Strauss argues that systemd improves security by making it easy to apply hardening techniques to the network services which he calls the "keepers of data attackers want." According to Strauss, I'm "fighting one of the most powerful tools we have to harden the front lines against the real attacks we see every day." Although systemd does make it easy to restrict the privileges of services, Strauss vastly overstates the value of these features.
The best systemd can offer is whole application sandboxing. You can start a daemon as a non-root user, in a restricted filesystem namespace, with mandatory access control. Sandboxing an entire application is an effective way to run potentially malicious code, since it protects other applications from the malicious one. This makes sandboxing useful on smartphones, which need to run many different untrustworthy, single-user applications. However, since sandboxing a whole application cannot protect one part of the application from a compromise of a different part, it is ineffective at securing benign-but-insecure software, which is the problem faced on servers. Server applications need to service requests from many different users. If one user is malicious and exploits a vulnerability in the application, whole application sandboxing doesn't protect the other users of the service.
For concrete examples, let's consider Apache and Samba, two daemons which Strauss says would benefit from systemd's features.
First Apache. You can start Apache as a non-root user provided someone else binds to ports 443 and 80. You can further sandbox it by preventing it from accessing parts of the filesystem it doesn't need to access. However, no matter how much you try to sandbox Apache, a typical setup is going to need a broad amount of access to do its job, including read permission to your entire website (including password-protected parts) and access to any credential (database password, API key, etc.) used by your CGI, PHP, or similar webapps.
Even under systemd's most restrictive sandboxing, an attacker who gains remote code execution in Apache would be able to read your entire website, alter responses to your visitors, steal your HTTPS private keys, and gain access to your database and any API consumed by your webapps. For most people, this would be the worst possible compromise, and systemd can do nothing to stop it. Systemd's sandboxing would prevent the attacker from gaining access to the rest of your system (absent a vulnerability in the kernel or systemd), but in today's world of single-purpose VMs and containers, that protection is increasingly irrelevant. The attacker probably only wants your database anyways.
To provide a meaningful improvement to security without rewriting in a memory-safe language, Apache would need to implement proper privilege separation. Privilege separation means using multiple processes internally, each running with different privileges and responsible for different tasks, so that a compromise while performing one task can't lead to the compromise of the rest of the application. For instance, the process that accepts HTTP connections could pass the request to a sandboxed process for parsing, and then pass the parsed request along to yet another process which is responsible for serving files and executing webapps. Privilege separation has been used effectively by OpenSSH, Postfix, qmail, Dovecot, and over a dozen daemons in OpenBSD . (Plus a couple of my own: titus and rdiscd .) However, privilege separation requires careful design to determine where to draw the privilege boundaries and how to interface between them. It's not something which an external tool such as systemd can provide. (Note: Apache already implements privilege separation that allows it to process requests as a non-root user, but it is too coarse-grained to stop the attacks described here.)
Next Samba, which is a curious choice of example by Strauss. Having configured Samba and professionally administered Windows networks, I know that Samba cannot run without full root privilege. The reason why Samba needs privilege is not because it binds to privileged ports, but because, as a file server, it needs the ability to assume the identity of any user so it can read and write that user's files. One could imagine a different design of Samba in which all files are owned by the same unprivileged user, and Samba maintains a database to track the real ownership of each file. This would allow Samba to run without privilege, but it wouldn't necessarily be more secure than the current design, since it would mean that a post-authentication vulnerability would yield access to everyone's files, not just those of the authenticated user. (Note: I'm not sure if Samba is able to contain a post-authentication vulnerability, but it theoretically could. It absolutely could not if it ran as a single user under systemd's sandboxing.)
Other daemons are similar. A mail server needs access to all users' mailboxes. If the mail server is written in C, and doesn't use privilege separation, sandboxing it with systemd won't stop an attacker with remote code execution from reading every user's mailbox. I could continue with other daemons, but I think I've made my point: systemd is not magic pixie dust that can be sprinkled on insecure server applications to make them secure. For protecting the "data attackers want," systemd is far from a "powerful" tool. I wouldn't be opposed to using a library or standalone tool to sandbox daemons as a last line of defense, but the amount of security it provides is not worth the baggage of running systemd as PID 1.
Achieving meaningful improvement in software security won't be as easy as adding a few lines to a systemd config file. It will require new approaches, new tools, new languages. Jon Evans sums it up eloquently :
... as an industry, let's at least set a trajectory . Let's move towards writing system code in better languages, first of all -- this should improve security and speed. Let's move towards formal specifications and verification of mission-critical code.
Systemd is not part of this trajectory. Systemd is more of the same old, same old, but with vastly more code and complexity, an illusion of security features, and, most troubling, lock-in. (Strauss dismisses my lock-in concerns by dishonestly claiming that applications aren't encouraged to use their non-standard DBUS API for DNS resolution. Systemd's own documentation says "Usage of this API is generally recommended to clients." And while systemd doesn't preclude alternative implementations, systemd's specifications are not developed through a vendor-neutral process like the IETF, so there is no guarantee that other implementers would have an equal seat at the table.) I have faith that the Linux ecosystem can correct its trajectory. Let's start now, and stop following systemd down the primrose path.
|
|
|
Jul 03, 2017 | thenewstack.io
Ubuntu, Fedora, Arch Linux and other Linux distributions have released patches for a serious arbitrary code execution vulnerability that could be exploited through malicious Domain Name System (DNS) packets.The flaw was found in systemd-resolved , a service that's part of the systemd initialization system adopted by many Linux distributions in recent years. The resolved service provides network name resolution to local applications by querying DNS servers.
The vulnerability, tracked as CVE-2017-9445 , was discovered by Chris Coulson , a software engineer at Canonical and member of the Ubuntu team, who noticed that when dealing with certain data packet sizes, systemd-resolved fails to allocate a sufficiently large buffer.
"A malicious DNS server can exploit this by responding with a specially crafted TCP payload to trick systemd-resolved to allocate a buffer that's too small, and subsequently write arbitrary data beyond the end of it," Coulson said in an advisory posted on the Open Source Security mailing list.
This could be exploited to crash the systemd-resolved daemon or to execute potentially malicious code in its context.
There are multiple ways in which an attacker could send malicious DNS packets to a Linux system with systemd-resolved running. One of them is by launching a man-in-the-middle attack on an insecure wireless network or through a compromised router.
Fortunately, not all Linux systems are affected because some distributions don't use systemd and even among those that do, not all of them include systemd-resolved. For example, SUSE and openSUSE distributions don't ship this component and, while Debian 9 (Stretch) includes it, the service is not enabled by default . The previous Debian versions don't have the vulnerable code at all.
Red Hat rated this vulnerability as important and assigned it a Common Vulnerability Scoring System (CVSS) score of 7.5, but determined that it does not affect the versions of systemd shipped with Red Hat Enterprise Linux 7. Fedora, however, is affected and has issued patches .
Ubuntu , Arch Linux and probably other distributions are also affected. Users should check if they have any updates pending for systemd and should deploy the patches as soon as possible. According to Coulson, the flaw was likely introduced in systemd version 223 in 2015 and affects all versions up to and including 233.
|
|
|
Jan 10, 2019 | securityaffairs.co
Security firm Qualys has disclosed three flaws (CVE-2018-16864, CVE-2018-16865, and CVE-2018-16866 ) in a component ofsystemd , a software suite that provides fundamental building blocks for a Linux operating system used in most major Linux distributions.The flaws reside in the
systemd –journald , a service of thesystemd that collects and stores logging data.Both CVE-2018-16864 and CVE-2018-16865 bugs are memory corruption vulnerabilities, while the CVE-2018-16866 is an out of bounds issue that can lead to an
information leak.Security patches for the three vulnerabilities are included in
distro repository since the coordinated disclosure, but some Linux distros such as some versions of Debian remain vulnerable. The flaws cannot be exploited in SUSE Linux Enterprise 15, openSUSE Leap 15.0, and Fedora 28 and 29 because their code is compiled with GCC's -fstack-clash-protection option.
|
|
|
Oct 29, 2018 | securityaffairs.co
Both Ubuntu and Red Hat Linux published a security advisory on the issue. summary :
" systemd – networkd is vulnerable to an out-of-bounds heap write in the DHCPv6 client when handling options sent by network adjacent DHCP servers. A attacker could exploit this via malicious DHCP server to corrupt heap memory on client machines, resulting in a denial of service or potential code execution." reads the advisory published by Red Hat."Felix Wilhelm discovered that systemd-networkd's dhcp6 client could be made to write beyond the bounds (buffer overflow) of a heap allocated buffer when responding to a dhcp6 server with an overly-long server-id parameter." reads the advisory published by Ubuntu.
The author of Systemd, Leonard Poettering, promptly published a security fix for Systemd-based Linux system relying on systemd-networkd.
|
|
|
Dec 16, 2018 | linux.slashdot.org
ArchieBunker ( 132337 ) , Tuesday October 30, 2018 @07:00PM ( #57565233 ) HomepageNew features include ( Score: 5 , Funny)All of
/etc has been moved to a flat binary database now called REGISTRY.DAT A new configuration tool known as regeditor authored by Poettering himself (accidental deletion of
/home only happens in rare occurrences) In kernel naughty words filter
systemd now includes a virtual userland previously known as busybox
|
|
|
Oct 26, 2018 | theregister.co.uk
Hole opens up remote-code execution to miscreants – or a crash, if you're lucky A security bug in Systemd can be exploited over the network to, at best, potentially crash a vulnerable Linux machine, or, at worst, execute malicious code on the box.
The flaw therefore puts Systemd-powered Linux computers – specifically those using systemd-networkd – at risk of remote hijacking: maliciously crafted DHCPv6 packets can try to exploit the programming cockup and arbitrarily change parts of memory in vulnerable systems, leading to potential code execution. This code could install malware, spyware, and other nasties, if successful.
The vulnerability – which was made public this week – sits within the written-from-scratch DHCPv6 client of the open-source Systemd management suite, which is built into various flavors of Linux.
This client is activated automatically if IPv6 support is enabled, and relevant packets arrive for processing. Thus, a rogue DHCPv6 server on a network, or in an ISP, could emit specially crafted router advertisement messages that wake up these clients, exploit the bug, and possibly hijack or crash vulnerable Systemd-powered Linux machines.
Here's the Red Hat Linux summary :
systemd-networkd is vulnerable to an out-of-bounds heap write in the DHCPv6 client when handling options sent by network adjacent DHCP servers. A attacker could exploit this via malicious DHCP server to corrupt heap memory on client machines, resulting in a denial of service or potential code execution.Felix Wilhelm, of the Google Security team, was credited with discovering the flaw, designated CVE-2018-15688 . Wilhelm found that a specially crafted DHCPv6 network packet could trigger "a very powerful and largely controlled out-of-bounds heap write," which could be used by a remote hacker to inject and execute code.
"The overflow can be triggered relatively easy by advertising a DHCPv6 server with a server-id >= 493 characters long," Wilhelm noted.
In addition to Ubuntu and Red Hat Enterprise Linux, Systemd has been adopted as a service manager for Debian, Fedora, CoreOS, Mint, and SUSE Linux Enterprise Server. We're told RHEL 7, at least, does not use the vulnerable component by default.
Systemd creator Lennart Poettering has already published a security fix for the vulnerable component – this should be weaving its way into distros as we type.
If you run a Systemd-based Linux system, and rely on systemd-networkd, update your operating system as soon as you can to pick up the fix when available and as necessary.
The bug will come as another argument against Systemd as the Linux management tool continues to fight for the hearts and minds of admins and developers alike. Though a number of major admins have in recent years adopted and championed it as the replacement for the old Init era, others within the Linux world seem to still be less than impressed with Systemd and Poettering's occasionally controversial management of the tool. ® Page:
2 3 Next →
MehAnonymous Coward , 6 daysAs anyone who bothers to read my comments (BTW "hi" to both of you) already knows, I despise systemd with a passion, but this one is more an IPv6 problem in general.
Yes this is an actual bug in networkd, but IPv6 seems to be far more bug prone than v4, and problems are rife in all implementations. Whether that's because the spec itself is flawed, or because nobody understands v6 well enough to implement it correctly, or possibly because there's just zero interest in making any real effort, I don't know, but it's a fact nonetheless, and my primary reason for disabling it wherever I find it. Which of course contributes to the "zero interest" problem that perpetuates v6's bug prone condition, ad nauseam.
IPv6 is just one of those tech pariahs that everyone loves to hate, much like systemd, albeit fully deserved IMO.
Oh yeah, and here's the obligatory "systemd sucks". Personally I always assumed the "d" stood for "destroyer". I believe the "IP" in "IPv6" stands for "Idiot Protocol".
Re: MehJay Lenovo , 6 days"nonetheless, and my primary reason for disabling it wherever I find it. "
The very first guide I read to hardening a system recommended disabling services you didn't need and emphasized IPV6 for the reasons you just stated.
Wasn't there a bux in Xorg reported recently as well?
https://www.theregister.co.uk/2018/10/25/x_org_server_vulnerability/
"FreeDesktop.org Might Formally Join Forces With The X.Org Foundation"
https://www.phoronix.com/scan.php?page=news_item&px=FreeDesktop-org-Xorg-Forces
Also, does this mean that Facebook was vulnerable to attack, again?
"Simply put, you could say Facebook loves systemd."
https://www.phoronix.com/scan.php?page=news_item&px=Facebook-systemd-2018
Re: Mehvtcodger , 6 daysIPv6 and SystemD: Forced industry standard diseases that requires most of us to bite our lips and bear it.
Fortunately, IPv6 by lack of adopted use, limits the scope of this bug.
Re: MehDougS , 6 daysFortunately, IPv6 by lack of adopted use, limits the scope of this bug.Yeah, fortunately IPv6 is only used by a few fringe organizations like Google and Microsoft.
Seriously, I personally want nothing to do with either systemd or IPv6. Both seem to me to fall into the bin labeled "If it ain't broke, let's break it" But still it's troubling that things that some folks regard as major system components continue to ship with significant security flaws. How can one trust anything connected to the Internet that is more sophisticated and complex than a TV streaming box?
Re: MehNate Amsden , 6 daysWas going to say the same thing, and I disable IPv6 for the exact same reason. IPv6 code isn't as well tested, as well audited, or as well targeted looking for exploits as IPv4. Stuff like this only proves that it was smart to wait, and I should wait some more.
Re: Mehbombastic bob , 6 daysCount me in the camp of who hates systemd(hates it being "forced" on just about every distro, otherwise wouldn't care about it - and yes I am moving my personal servers to Devuan, thought I could go Debian 7->Devuan but turns out that may not work, so I upgraded to Debian 8 a few weeks ago, and will go to Devuan from there in a few weeks, upgraded one Debian 8 to Devuan already 3 more to go -- Debian user since 1998), when reading this article it reminded me of
https://www.theregister.co.uk/2017/06/29/systemd_pwned_by_dns_query/
The gift that keeps on giving (systemd) !!!Long John Brass , 6 daysThis makes me glad I'm using FreeBSD. The Xorg version in FreeBSD's ports is currently *slightly* older than the Xorg version that had that vulnerability in it. AND, FreeBSD will *NEVER* have systemd in it!
(and, for Linux, when I need it, I've been using Devuan)
That being said, the whole idea of "let's do a re-write and do a 'systemd' instead of 'system V init' because WE CAN and it's OUR TURN NOW, 'modern' 'change for the sake of change' etc." kinda reminds me of recent "update" problems with Win-10-nic...
Oh, and an obligatory Schadenfreude laugh: HA HA HA HA HA HA HA HA HA HA HA HA HA HA HA HA HA HA HA HA HA HA HA HA HA HA HA HA HA HA HA HA HA HA HA HA HA HA HA HA HA HA HA HA HA HA HA HA HA HA HA HA HA HA HA HA HA HA HA HA HA HA HA!!!!!!!!!!!!!!!!!!!
Re: The gift that keeps on giving (systemd) !!!Dan 55 , 6 daysFinally got all my machines cut over from Debian to Devuan.
Might spin a FreeBSD system up in a VM and have a play.
I suspect that the infestation of stupid into the Linux space won't stop with or be limited to SystemD. I will wait and watch to see what damage the re-education gulag has done to Sweary McSwearFace (Mr Torvalds)
Re: MehOrv , 3 daysI despise systemd with a passion, but this one is more an IPv6 problem in general.
Not really, systemd has its tentacles everywhere and runs as root. Exploits which affect systemd therefore give you the keys to the kingdom.
Re: MehLong John Brass , 3 daysNot really, systemd has its tentacles everywhere and runs as root.Yes, but not really the problem in this case. Any DHCP client is going to have to run at least part of the time as root. There's not enough nuance in the Linux privilege model to allow it to manipulate network interfaces, otherwise.
4 1Re: MehJohnFen , 6 daysYes, but not really the problem in this case. Any DHCP client is going to have to run at least part of the time as root. There's not enough nuance in the Linux privilege model to allow it to manipulate network interfaces, otherwise.Sorry but utter bullshit. You can if you are so inclined you can use the Linux Capabilities framework for this kind of thing. See https://wiki.archlinux.org/index.php/capabilities
3 0Yay for meElReg!comments!Pierre , 2 days"If you run a Systemd-based Linux system"
I remain very happy that I don't use systemd on any of my machines anymore. :)
"others within the Linux world seem to still be less than impressed with Systemd"
Yep, I'm in that camp. I gave it a good, honest go, but it increased the amount of hassle and pain of system management without providing any noticeable benefit, so I ditched it.
Re: Time to trollDestroy All Monsters , 5 days> Just like it's entirely possible to have a Linux system without any GNU in it
Just like it's possible to have a GNU system without Linux on it - ho well as soon as GNU MACH is finally up to the task ;-)
On the systemd angle, I, too, am in the process of switching all my machines from Debian to Devuan but on my personnal(*) network a few systemd-infected machines remain, thanks to a combination of laziness from my part and stubborn "systemd is quite OK" attitude from the raspy foundation. That vuln may be the last straw : one on the aforementionned machines sits on my DMZ, chatting freely with the outside world. Nothing really crucial on it, but i'd hate it if it became a foothold for nasties on my network.
(*) policy at work is RHEL, and that's negociated far above my influence level, but I don't really care as all my important stuff runs on Z/OS anyway ;-) . Ok we have to reboot a few VMs occasionnally when systemd throws a hissy fit -which is surprisingly often for an "enterprise" OS -, but meh.
Re: Not possibleAnonymous Coward , 5 daysThis code is actually pretty bad and should raise all kinds of red flags in a code review.
Re: Not possibleChristian Berger , 5 daysITYM Lennart
Re: Not possiblejake , 6 days"This code is actually pretty bad and should raise all kinds of red flags in a code review."
Yeah, but for that you need people who can do code reviews, and also people who can accept criticism. That also means saying "no" to people who are bad at coding, and saying that repeatedly if they don't learn.
SystemD seems to be the area where people gather who want to get code in for their resumes, not for people who actually want to make the world a better place.
26 1There is a reason ...AdamWill , 6 days... that an init, traditionally, is a small bit of code that does one thing very well. Like most of the rest of the *nix core utilities. All an init should do is start PID1, set run level, spawn a tty (or several), handle a graceful shutdown, and log all the above in plaintext to make troubleshooting as simplistic as possible. Anything else is a vanity project that is best placed elsewhere, in it's own stand-alone code base.
Inventing a clusterfuck init variation that's so big and bulky that it needs to be called a "suite" is just asking for trouble.
IMO, systemd is a cancer that is growing out of control, and needs to be cut out of Linux before it infects enough of the system to kill it permanently.
Re: There is a reason ...Anonymous Coward , 4 daysThat's why systemd-networkd is a separate, optional component, and not actually part of the init daemon at all. Most systemd distros do not use it by default and thus are not vulnerable to this unless the user actively disables the default network manager and chooses to use networkd instead.
Re: There is a reason ...Orv , 3 days"Just go install a default Fedora or Ubuntu system and check for yourself: you'll have systemd, but you *won't* have systemd-networkd running."
Funny that I installed ubuntu 18.04 a few weeks ago and the fucking thing installed itself then! ( and was a fucking pain to remove).
LP is a fucking arsehole.
Re: There is a reason ...AdamWill , 2 daysPardon my ignorance (I don't use a distro with systemd) why bother with networkd in the first place if you don't have to use it.Mostly because the old-style init system doesn't cope all that well with systems that move from network to network. It works for systems with a static IP, or that do a DHCP request at boot, but it falls down on anything more dynamic.
In order to avoid restarting the whole network system every time they switch WiFi access points, people have kludged on solutions like NetworkManager. But it's hard to argue it's more stable or secure than networkd. And this is always going to be a point of vulnerability because anything that manipulates network interfaces will have to be running as root.
These days networking is essential to the basic functionality of most computers; I think there's a good argument that it doesn't make much sense to treat it as a second-class citizen.
Re: There is a reason ...alain williams , 6 days"Funny that I installed ubuntu 18.04 a few weeks ago and the fucking thing installed itself then! ( and was a fucking pain to remove)."
So I looked into it a bit more, and from a few references at least, it seems like Ubuntu has a sort of network configuration abstraction thingy that can use both NM and systemd-networkd as backends; on Ubuntu desktop flavors NM is usually the default, but apparently for recent Ubuntu Server, networkd might indeed be the default. I didn't notice that as, whenever I want to check what's going on in Ubuntu land, I tend to install the default desktop spin...
"LP is a fucking arsehole."
systemd's a lot bigger than Lennart, you know. If my grep fu is correct, out of 1543 commits to networkd, only 298 are from Lennart...
1 0Old is goodoiseau , 4 daysin many respects when it comes to software because, over time, the bugs will have been found and squashed. Systemd brings in a lot of new code which will, naturally, have lots of bugs that will take time to find & remove. This is why we get problems like this DHCP one.
Much as I like the venerable init: it did need replacing. Systemd is one way to go, more flexible, etc, etc. Something event driven is a good approach.
One of the main problems with systemd is that it has become too big, slurped up lots of functionality which has removed choice, increased fragility. They should have concentrated on adding ways of talking to existing daemons, eg dhcpd, through an API/something. This would have reused old code (good) and allowed other implementations to use the API - this letting people choose what they wanted to run.
But no: Poettering seems to want to build a Cathedral rather than a Bazzar.
He appears to want to make it his way or no way. This is bad, one reason that *nix is good is because different solutions to a problem have been able to be chosen, one removed and another slotted in. This encourages competition and the 'best of breed' comes out on top. Poettering is endangering that process.
Also: he refusal to accept patches to let it work on non-Linux Unix is just plain nasty.
Re: Old is goodRich 2 , 4 daysHello:
One of the main problems with systemd is that it has become too big, slurped up lots of functionality which has removed choice, increased fragility.
IMO, there is a striking paralell between systemd and the registry in Windows OSs.
After many years of dealing with the registry (W98 to XPSP3) I ended up seeing the registry as a sort of developer sanctioned virus running inside the OS, constantly changing and going deeper and deeper into the OS with every iteration and as a result, progressively putting an end to the possibility of knowing/controlling what was going on inside your box/the OS.
Years later, when I learned about the existence of systemd (I was already running Ubuntu) and read up on what it did and how it did it, it dawned on me that systemd was nothing more than a registry class virus and it was infecting Linux_land at the behest of the developers involved.
So I moved from Ubuntu to PCLinuxOS and then on to Devuan.
Call me paranoid but I am convinced that there are people both inside and outside IT that actually want this and are quite willing to pay shitloads of money for it to happen.
I don't see this MS cozying up to Linux in various ways lately as a coincidence: these things do not happen just because or on a senior manager's whim.
What I do see (YMMV) is systemd being a sort of convergence of Linux with Windows, which will not be good for Linux and may well be its undoing.
Cheers,
O.
Re: Old is goodMichael Wojcik , 3 days"Also: he refusal to accept patches to let it work on non-Linux Unix is just plain nasty"
Thank goodness this crap is unlikely to escape from Linux!
By the way, for a systemd-free Linux, try void - it's rather good.
Re: Old is goodOrv , 3 daysMuch as I like the venerable init: it did need replacing.
For some use cases, perhaps. Not for any of mine. SysV init, or even BSD init, does everything I need a Linux or UNIX init system to do. And I don't need any of the other crap that's been built into or hung off systemd, either.
Re: Old is goodChairman of the Bored , 6 daysBSD init and SysV init work pretty darn well for their original purpose -- servers with static IP addresses that are rebooted no more than once in a fortnight. Anything more dynamic starts to give it trouble.
Too bad Linus swore off swearingjake , 6 daysSituations like this go beyond a little "golly gee, I screwed up some C"...
Re: Too bad Linus swore off swearingJLV , 6 daysLinus doesn't care. systemd has nothing to do with the kernel ... other than the fact that the lead devs for systemd have been banned from working on the kernel because they don't play nice with others.
how did it get to this?Doctor Syntax , 6 daysI've been using runit, because I am too lazy and clueless to write init scripts reliably. It's very lightweight, runs on a bunch of systems and really does one thing - keep daemons up.
I am not saying it's the best - but it looks like it has a very small codebase, it doesn't do much and generally has not bugged me after I configured each service correctly. I believe other systems also exist to avoid using init scripts directly. Not Monit, as it relies on you configuring the daemon start/stop commands elsewhere.
On the other hand, systemd is a massive sprawl, does a lot of things - some of them useful, like dependencies and generally has needed more looking after. Twice I've had errors on a Django server that, after a lot of looking around ended up because something had changed in the, Chef-related, code that's exposed to systemd and esoteric (not emitted by systemd) errors resulted when systemd could not make sense of the incorrect configuration.
I don't hate it - init scripts look a bit antiquated to me and they seem unforgiving to beginners - but I don't much like it. What I certainly do hate is how, in an OS that is supposed to be all about choice, sometime excessively so as in the window manager menagerie, we somehow ended up with one mandatory daemon scheduler on almost all distributions. Via, of all types of dependencies, the GUI layer. For a window manager that you may not even have installed.
Talk about the antithesis of the Unix philosophy of do one thing, do it well.
Oh, then there are also the security bugs and the project owner is an arrogant twat. That too.
Re: how did it get to this?onefang , 6 days"init scripts look a bit antiquated to me and they seem unforgiving to beginners"
Init scripts are shell scripts. Shell scripts are as old as Unix. If you think that makes them antiquated then maybe Unix-like systems are not for you. In practice any sub-system generally gets its own scripts installed with the rest of the S/W so if being unforgiving puts beginners off tinkering with them so much the better. If an experienced Unix user really needs to modify one of the system-provided scripts their existing shell knowledge will let them do exactly what's needed. In the extreme, if you need to develop a new init script then you can do so in the same way as you'd develop any other script - edit and test from the command line.
33 4Re: how did it get to this?sed gawk , 6 days"Init scripts are shell scripts."
While generally true, some sysv init style inits can handle init "scripts" written in any language.
Re: how did it get to this?AdamWill , 6 daysI personally like openrc as an init system, but systemd is a symptom of the tooling problem.
It's for me a retrograde step but again, it's linux, one can, as you and I do, just remove systemd.
There are a lot of people in the industry now who don't seem able to cope with shell scripts nor are minded to research the arguments for or against shell as part of a unix style of system design.
In conclusion, we are outnumbered, but it will eventually collapse under its own weight and a worthy successor shall rise, perhaps called SystemV, might have to shorten that name a bit.
Just about nothing actually uses networkdChristian Berger , 5 days"In addition to Ubuntu and Red Hat Enterprise Linux, Systemd has been adopted as a service manager for Debian, Fedora, CoreOS, Mint, and SUSE Linux Enterprise Server. We're told RHEL 7, at least, does not use the vulnerable component by default."
I can tell you for sure that no version of Fedora does, either, and I'm fairly sure that neither does Debian, SLES or Mint. I don't know anything much about CoreOS, but https://coreos.com/os/docs/latest/network-config-with-networkd.html suggests it actually *might* use systemd-networkd.
systemd-networkd is not part of the core systemd init daemon. It's an optional component, and most distros use some other network manager (like NetworkManager or wicd) by default.
The important word here is "still"NLCSGRV , 6 daysI mean commercial distributions seem to be particularly interested in trying out new things that can increase their number of support calls. It's probably just that networkd is either to new and therefore not yet in the release, or still works so badly even the most rudimentary tests fail.
There is no reason to use that NTP daemon of systemd, yet more and more distros ship with it enabled, instead of some sane NTP-server.
The Curse of Poettering strikes again._LC_ , 6 daysNow hang on, please!Ken Hagan , 6 daysSer iss no neet to worry, systemd will becum stable soon after PulseAudio does.
Re: Now hang on, please!Obesrver1 , 5 daysI won't hold my breath, then. I have a laptop at the moment that refuses to boot because (as I've discovered from looking at the journal offline) pulseaudio is in an infinite loop waiting for the successful detection of some hardware that, presumably, I don't have.
I imagine I can fix it by hacking the file-system (offline) so that fuckingpulse is no longer part of the boot configuration, but I shouldn't have to. A decent init system would be able to kick of everything else in parallel and if one particular service doesn't come up properly then it just logs the error. I *thought* that was one of the claimed advantages of systemd, but apparently that's just a load of horseshit.
26 0Reason for disabling IVP6Orv , 3 daysThat it punches thru NAT routers enabling all your little goodies behind them as directly accessible.
MS even supplies tunneling (Ivp4 to Ivp6) so if using Linux in a VM on a MS system you may still have it anyway.
NAT was always recommended to be used in hardening your system, I prefer to keep all my idIoT devices behind one.
As they are just Idiot devices.
In future I will need a NAT that acts as a DNS and offers some sort of solution to keeping Ivp4.
Re: Reason for disabling IVP6dajames , 3 daysMy NAT router statefully firewalls incoming IPv6 by default, which I consider equivalently secure. NAT adds security mostly by accident, because it de-facto adds a firewall that blocks incoming packets. It's not the address translation itself that makes things more secure, it's the inability to route in from the outside.
Re: Reason for disabling IVP6JohnFen , 3 daysYou can use NAT with IPv6.
You can, but why would you want to.
NAT is schtick for connecting a whole LAN to a WAN using a single IPv4 address (useful with IPv4 because most ISPs don't give you a /24 when you sign up). If you have a native IPv6 address you'll have something like 2^64 addresses, so machines on your LAN can have an actual WAN-visible address of their own without needing a trick like NAT.
Using NAT with IPv6 is just missing the point.
Re: Reason for disabling IVP6Destroy All Monsters , 5 days"so machines on your LAN can have an actual WAN-visible address of their own without needing a trick like NAT."
Avoiding that configuration is exactly the use case for using NAT with IPv6. As others have pointed out, you can accomplish the same thing with IPv6 router configuration, but NAT is easier in terms of configuration and maintenance. Given that, and assuming that you don't want to be able to have arbitrary machines open ports that are visible to the internet, then why not use NAT?
Also, if your goal is to make people more likely to move to IPv6, pointing out IPv4 methods that will work with IPv6 (even if you don't consider them optimal) seems like a really, really good idea. It eases the transition.
Please El Reg these stories make ma rage at breakfast, what's this?TheSkunkyMonk , 5 daysThe bug will come as another argument against Systemd as the Linux management tool continues to fight for the hearts and minds of admins and developers alike.
Less against systemd (which should get attacked on the design & implementation level) or against IPv6 than against the use of buffer-overflowable languages in 2018 in code that processes input from the Internet (it's not the middle ages anymore) or at least very hard linting of the same.
But in the end, what did it was a violation of the Don't Repeat Yourself principle and lack of sufficently high-level datastructures. Pointer into buffer, and the remaining buffer length are two discrete variables that need to be updated simultaneously to keep the invariant and this happens in several places. This is just a catastrophe waiting to happen. You forget to update it once, you are out! Use structs and functions updating the structs correctly.
And use assertions in the code , this stuff all seems disturbingly assertion-free.
Excellent explanation by Felix Wilhelm:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1795921
The function receives a pointer to the option buffer buf, it's remaining size buflen and the IA to be added to the buffer. While the check at (A) tries to ensure that the buffer has enough space left to store the IA option, it does not take the additional 4 bytes from the DHCP6Option header into account (B). Due to this the memcpy at (C) can go out-of-bound and *buflen can underflow [i.e. you suddenly have a gazillion byte buffer, Ed.] in (D) giving an attacker a very powerful and largely controlled OOB heap write starting at (E).
Init is 1026 lines of code in one file and it works great.Anonymous Coward , 5 days"...and Poettering's occasionally controversial management of the tool."clocKwize , 4 daysShouldn't that be "...Potterings controversial management as a tool."?
Re: Contractor rightsAnonymous Coward , 4 dayswhy don't we stop writing code in languages that make it easy to screw up so easily like this?
There are plenty about nowadays, I'd rather my DHCP client be a little bit slower at processing packets if I had more confidence it would not process then incorrectly and execute code hidden in said packets...
Switch, as easy as thatoiseau , 3 daysThe circus that is called "Linux" have forced me to Devuan and the likes however the circus is getting worse and worse by the day, thus I have switched to the BSD world, I will learn that rather than sit back and watch this unfold As many of us have been saying, the sudden switch to SystemD was rather quick, perhaps you guys need to go investigate why it really happened, don't assume you know, go dig and you will find the answers, it's rather scary, thus I bid the Linux world a farewell after 10 years of support, I will watch the grass dry out from the other side of the fence, It was destined to fail by means of infiltration and screw it up motive(s) on those we do not mention here.
Re: Switch, as easy as thatDave Bell , 4 daysHello:
As many of us have been saying, the sudden switch to SystemD was rather quick, perhaps you guys need to go investigate why it really happened, don't assume you know, go dig and you will find the answers, it's rather scary ...
Indeed, it was rather quick and is very scary.
But there's really no need to dig much, just reason it out.
It's like a follow the money situation of sorts.
I'll try to sum it up in three short questions:
Q1: Hasn't the Linux philosophy (programs that do one thing and do it well) been a success?
A1: Indeed, in spite of the many init systems out there, it has been a success in stability and OS management. And it can easily be tested and debugged, which is an essential requirement.
Q2: So what would Linux need to have the practical equivalent of the registry in Windows for?
A2: So that whatever the registry does in/to Windows can also be done in/to Linux.
Q3: I see. And just who would want that to happen? Makes no sense, it is a huge step backwards.
A3: ....
Cheers,
O.
Reporting weaknessW.O.Frobozz , 3 daysOK, so I was able to check through the link you provided, which says "up to and including 239", but I had just installed a systemd update and when you said there was already a fix written, working it's way through the distro update systems, all I had to do was check my log.
Linux Mint makes it easy.
But why didn't you say something such as "reported to affect systemd versions up to and including 239" and then give the link to the CVE? That failure looks like rather careless journalism.
Hmm./sbin/init never had these problems. But then again /sbin/init didn't pretend to be the entire operating system.
|
|
|
Oct 29, 2018 | lxer.com
- The Register; By Shaun Nichols (Posted by the_doctor on Oct 28, 2018 12:18 PM EDT)
- Story Type: News Story , Security ; Groups: Debian , Developer , Distributions , Fedora , Linux , Mint , Red Hat , SUSE , Ubuntu
A security bug in Systemd can be exploited over the network to, at best, potentially crash a vulnerable Linux machine, or, at worst, execute malicious code on the box... Systemd creator Leonard Poettering has already published a security fix for the vulnerable component – this should be weaving its way into distros as we type.
|
|
|
Oct 15, 2018 | blog.ungleich.ch
Let's say every car manufacturer recently discovered a new technology named "doord", which lets you open up car doors much faster than before. It only takes 0.05 seconds, instead of 1.2 seconds on average. So every time you open a door, you are much, much faster!
Many of the manufacturers decide to implement doord, because the company providing doord makes it clear that it is beneficial for everyone. And additional to opening doors faster, it also standardises things. How to turn on your car? It is the same now everywhere, it is not necessarily to look for the keyhole anymore.
Unfortunately though, sometimes doord does not stop the engine. Or if it is cold outside, it stops the ignition process, because it takes too long. Doord also changes the way how your navigation system works, because that is totally related to opening doors, but leads to some users being unable to navigate, which is accepted as collateral damage. In the end, you at least have faster door opening and a standard way to turn on the car. Oh, and if you are in a traffic jam and have to restart the engine often, it will stop restarting it after several times, because that's not what you are supposed to do. You can open the engine hood and tune that setting though, but it will be reset once you buy a new car.
|
|
|
Oct 15, 2018 | linux.slashdot.org
AntiSol ( 1329733 ) , Saturday August 29, 2015 @03:52PM ( #50417111 )Re:Approaching the Singularity ( Score: 4 , Funny)Future History of Init Systems
Future History of Init Systems
- 2015: systemd becomes default boot manager in debian.
- 2017: "complete, from-scratch rewrite" [jwz.org]. In order to not have to maintain backwards compatibility, project is renamed to system-e.
- 2019: debut of systemf, absorbtion of other projects including alsa, pulseaudio, xorg, GTK, and opengl.
- 2021: systemg maintainers make the controversial decision to absorb The Internet Archive. Systemh created as a fork without Internet Archive.
- 2022: systemi, a fork of systemf focusing on reliability and minimalism becomes default debian init system.
- 2028: systemj, a complete, from-scratch rewrite is controversial for trying to reintroduce binary logging. Consensus is against the systemj devs as sysadmins remember the great systemd logging bug of 2017 unkindly. Systemj project is eventually abandoned.
- 2029: systemk codebase used as basis for a military project to create a strong AI, known as "project skynet". Software behaves paradoxically and project is terminated.
- 2033: systeml - "system lean" - a "back to basics", from-scratch rewrite, takes off on several server platforms, boasting increased reliability. systemm, "system mean", a fork, used in security-focused distros.
- 2117: critical bug discovered in the long-abandoned but critical and ubiquitous system-r project. A new project, system-s, is announced to address shortcomings in the hundred-year-old codebase. A from-scratch rewrite begins.
- 2142: systemu project, based on a derivative of systemk, introduces "Artificially intelligent init system which will shave 0.25 seconds off your boot time and absolutely definitely will not subjugate humanity". Millions die. The survivors declare "thou shalt not make an init system in the likeness of the human mind" as their highest law.
- 2147: systemv - a collection of shell scripts written around a very simple and reliable PID 1 introduced, based on the brand new religious doctrines of "keep it simple, stupid" and "do one thing, and do it well". People's computers start working properly again, something few living people can remember. Wyld Stallyns release their 94th album. Everybody lives in peace and harmony.
|
|
|
Oct 15, 2018 | linux.slashdot.org
thegarbz ( 1787294 ) , Sunday August 30, 2015 @04:08AM ( #50419549 )Re:Hang on a minute... ( Score: 5 , Funny)I honestly, seriously sometimes wonder if systemd is Skynet... or, a way for Skynet to 'waken'.Skynet begins to learn at a geometric rate. It becomes self-aware at 2:14 a.m. Eastern time, August 29th. At 2:15am it crashes. No one knows why. The binary log file was corrupted in the process and is unrecoverable.
All anyone could remember is a bug listed in the systemd bug tracker talking about su which was classified as WON'T FIX as the developer thought it was a broken concept.
|
|
|
Oct 15, 2018 | linux.slashdot.org
Anonymous Coward , Saturday August 29, 2015 @11:37AM ( #50415825 )Cryptic command names ( Score: 5 , Funny)Great to see that systemd is finally doing something about all of those cryptic command names that plague the unix ecosystem.
Upcoming systemd re-implementations of standard utilities: ls to be replaced by filectl directory contents [pathname] grep to be replaced by datactl file contents search [plaintext] (note: regexp no longer supported as it's ambiguous) gimp to be replaced by imagectl open file filename draw box [x1,y1,x2,y2] draw line [x1,y1,x2,y2] ...
Anonymous Coward , Saturday August 29, 2015 @11:58AM ( #50415939 )Re: Cryptic command names ( Score: 3 , Funny)Oh look, another Powershell
|
|
|
Oct 15, 2018 | linux.slashdot.org
RabidReindeer ( 2625839 ) , Saturday August 29, 2015 @11:38AM ( #50415833 )What's with all the awkward systemd command names? ( Score: 5 , Insightful)I know systemd sneers at the old Unix convention of keeping it simple, keeping it separate, but that's not the only convention they spit on. God intended Unix (Linux) commands to be cryptic things 2-4 letters long (like "su", for example). Not "systemctl", "machinectl", "journalctl", etc. Might as well just give everything a 47-character long multi-word command like the old Apple commando shell did.
Seriously, though, when you're banging through system commands all day long, it gets old and their choices aren't especially friendly to tab completion. On top of which why is "machinectl" a shell and not some sort of hardware function? They should have just named the bloody thing command.com.
|
|
|
Jun 01, 2017 | www.cyberciti.biz
There is a serious vulnerability in sudo command that grants root access to anyone with a shell account. It works on SELinux enabled systems such as CentOS/RHEL and others too. A local user with privileges to execute commands via sudo could use this flaw to escalate their privileges to root. Patch your system as soon as possible.
It was discovered that Sudo did not properly parse the contents of /proc/[pid]/stat when attempting to determine its controlling tty. A local attacker in some configurations could possibly use this to overwrite any file on the filesystem, bypassing intended permissions or gain root shell.
... ... ...
A list of affected Linux distro
- Red Hat Enterprise Linux 6 (sudo)
- Red Hat Enterprise Linux 7 (sudo)
- Red Hat Enterprise Linux Server (v. 5 ELS) (sudo)
- Oracle Enterprise Linux 6
- Oracle Enterprise Linux 7
- Oracle Enterprise Linux Server 5
- CentOS Linux 6 (sudo)
- CentOS Linux 7 (sudo)
- Debian wheezy
- Debian jessie
- Debian stretch
- Debian sid
- Ubuntu 17.04
- Ubuntu 16.10
- Ubuntu 16.04 LTS
- Ubuntu 14.04 LTS
- SUSE Linux Enterprise Software Development Kit 12-SP2
- SUSE Linux Enterprise Server for Raspberry Pi 12-SP2
- SUSE Linux Enterprise Server 12-SP2
- SUSE Linux Enterprise Desktop 12-SP2
- OpenSuse, Slackware, and Gentoo Linux
|
|
|
Aug 30, 2015 | blog.erratasec.com
Stefan Anica said...This article is more full of bullshit than a bull stable .... with shit in it.Don il said...
BTW, comments such as next:"This article is more full of bullshit than a bull stable .... with shit in it."
bring to my mind all the comments from Microsoft fans/paid-for-shills in other forums. They tend to attack anyone not accepting things imposed on them.
|
|
|
First of all this is kind of system error that is not easy to exploit. You need to locate the vulnerable functions in core image and be able to overwrite them via call (length of which any reasonable programmer will check). So whether this vulnerability is exploitable or not for applications that we are running is an open question.
In any case most installed systems are theoretically vilnerable. Practically too if they are running applications that do not check length for such system calls.
Only recently patched systems with glibc-2.11.3-17.74.13.x86_64 and above are not vulnerable.
|
|
|
September 25, 2014 | troyhunt.com
Remember Heartbleed? If you believe the hype today, Shellshock is in that league and with an equally awesome name albeit bereft of a cool logo (someone in the marketing department of these vulns needs to get on that). But in all seriousness, it does have the potential to be a biggie and as I did with Heartbleed, I wanted to put together something definitive both for me to get to grips with the situation and for others to dissect the hype from the true underlying risk.To set the scene, let me share some content from Robert Graham's blog post who has been doing some excellent analysis on this. Imagine an HTTP request like this:
target = 0.0.0.0/0 port = 80 banners = true http-user-agent = shellshock-scan (http://blog.erratasec.com/2014/09/bash-shellshock-scan-of-internet.html) http-header = Cookie:() { :; }; ping -c 3 209.126.230.74 http-header = Host:() { :; }; ping -c 3 209.126.230.74 http-header = Referer:() { :; }; ping -c 3 209.126.230.74Which, when issued against a range of vulnerable IP addresses, results in this:
|
|
|
en.wikipedia.org
Analysis of the source code history of Bash shows that the vulnerabilities had existed undiscovered since approximately version 1.13 in 1992.[4] The maintainers of the Bash source code have difficulty pinpointing the time of introduction due to the lack of comprehensive changelogs.[1]
In Unix-based operating systems, and in other operating systems that Bash supports, each running program has its own list of name/value pairs called environment variables. When one program starts another program, it provides an initial list of environment variables for the new program.[14] Separately from these, Bash also maintains an internal list of functions, which are named scripts that can be executed from within the program.[15] Since Bash operates both as a command interpreter and as a command, it is possible to execute Bash from within itself. When this happens, the original instance can export environment variables and function definitions into the new instance.[16] Function definitions are exported by encoding them within the environment variable list as variables whose values begin with parentheses ("()") followed by a function definition. The new instance of Bash, upon starting, scans its environment variable list for values in this format and converts them back into internal functions. It performs this conversion by creating a fragment of code from the value and executing it, thereby creating the function "on-the-fly", but affected versions do not verify that the fragment is a valid function definition.[17] Therefore, given the opportunity to execute Bash with a chosen value in its environment variable list, an attacker can execute arbitrary commands or exploit other bugs that may exist in Bash's command interpreter.
The name "shellshock" is attributed[by whom?][not in citation given] to Andreas Lindh from a tweet on 24 September 2014.[18][non-primary source needed]
On October 1st, Zalewski released details of the final bugs, and confirmed that Florian's patch does indeed prevent them. Zalewski says fixed
CGI-based web server attack
When a web server uses the Common Gateway Interface (CGI) to handle a document request, it passes various details of the request to a handler program in the environment variable list. For example, the variable HTTP_USER_AGENT has a value that, in normal usage, identifies the program sending the request. If the request handler is a Bash script, or if it executes one for example using the system(3) call, Bash will receive the environment variables passed by the server and will process them as described above. This provides a means for an attacker to trigger the Shellshock vulnerability with a specially crafted server request.[4] The security documentation for the widely used Apache web server states: "CGI scripts can ... be extremely dangerous if they are not carefully checked."[20] and other methods of handling web server requests are often used. There are a number of online services which attempt to test the vulnerability against web servers exposed to the Internet.[citation needed]
SSH server example
OpenSSH has a "ForceCommand" feature, where a fixed command is executed when the user logs in, instead of just running an unrestricted command shell. The fixed command is executed even if the user specified that another command should be run; in that case the original command is put into the environment variable "SSH_ORIGINAL_COMMAND". When the forced command is run in a Bash shell (if the user's shell is set to Bash), the Bash shell will parse the SSH_ORIGINAL_COMMAND environment variable on start-up, and run the commands embedded in it. The user has used their restricted shell access to gain unrestricted shell access, using the Shellshock bug.[21]
DHCP example
Some DHCP clients can also pass commands to Bash; a vulnerable system could be attacked when connecting to an open Wi-Fi network. A DHCP client typically requests and gets an IP address from a DHCP server, but it can also be provided a series of additional options. A malicious DHCP server could provide, in one of these options, a string crafted to execute code on a vulnerable workstation or laptop.[9]
Note of offline system vulnerability
The bug can potentially affect machines that are not directly connected to the Internet when performing offline processing, which involves the use of Bash.[citation needed]
Initial report (CVE-2014-6271)
This original form of the vulnerability involves a specially crafted environment variable containing an exported function definition, followed by arbitrary commands. Bash incorrectly executes the trailing commands when it imports the function.[22] The vulnerability can be tested with the following command:
env x='() { :;}; echo vulnerable' bash -c "echo this is a test"In systems affected by the vulnerability, the above commands will display the word "vulnerable" as a result of Bash executing the command "echo vulnerable", which was embedded into the specially crafted environment variable named "x".[23][24]
There was an initial report of the bug made to the maintainers of Bash (Report# CVE-2014-6271). The bug was corrected with a patch to the program. However, after the release of the patch there were subsequent reports of different, yet related vulnerabilities. On 26 September 2014, two open-source contributors, David A. Wheeler and Norihiro Tanaka, noted that there were additional issues, even after patching systems using the most recently available patches. In an email addressed to the oss-sec list and the bash bug list, Wheeler wrote: "This patch just continues the 'whack-a-mole' job of fixing parsing errors that began with the first patch. Bash's parser is certain [to] have many many many other vulnerabilities".[25]
On 27 September 2014, Michal Zalewski announced his discovery of several other Bash vulnerabilities,[26] one based upon the fact that Bash is typically compiled without address space layout randomization.[27] Zalewski also strongly encouraged all concerned to immediately apply a patch made available by Florian Weimer.[26][27]CVE-2014-6277
CVE-2014-6277 relates to the parsing of function definitions in environment variables by Bash. It was discovered by Michał Zalewski.[26][27][28][29]
This causes a segfault.
() { x() { _; }; x() { _; } <<a; }CVE-2014-6278
CVE-2014-6278 relates to the parsing of function definitions in environment variables by Bash. It was discovered by Michał Zalewski.[30][29]
() { _; } >_[$($())] { echo hi mom; id; }CVE-2014-7169
On the same day the bug was published, Tavis Ormandy discovered a related bug which was assigned the CVE identifier CVE-2014-7169.[21] Official and distributed patches for this began releasing on 26 September 2014.[citation needed] Demonstrated in the following code:
env X='() { (a)=>\' sh -c "echo date"; cat echowhich would trigger a bug in Bash to execute the command "date" unintentionally. This would become CVE-2014-7169.[21]
- Testing example
Here is an example of a system that has a patch for CVE-2014-6271 but not CVE-2014-7169:
$ X='() { (a)=>\' bash -c "echo date" bash: X: line 1: syntax error near unexpected token `=' bash: X: line 1: `' bash: error importing function definition for `X' $ cat echo Fri Sep 26 01:37:16 UTC 2014The patched system displays the same error, notifying the user that CVE-2014-6271 has been prevented. However, the attack causes the writing of a file named 'echo', into the working directory, containing the result of the 'date' call. The existence of this issue resulted in the creation of CVE-2014-7169 and the release patches for several systems.
A system patched for both CVE-2014-6271 and CVE-2014-7169 will simply echo the word "date" and the file "echo" will not be created.
$ X='() { (a)=>\' bash -c "echo date" date $ cat echo cat: echo: No such file or directoryCVE-2014-7186
CVE-2014-7186 relates to an out-of-bounds memory access error in the Bash parser code.[31] While working on patching Shellshock, Red Hat researcher Florian Weimer found this bug.[23]
- Testing example
Here is an example of the vulnerability, which leverages the use of multiple "<<EOF" declarations:
bash -c 'true <<EOF <<EOF <<EOF <<EOF <<EOF <<EOF <<EOF <<EOF <<EOF <<EOF <<EOF <<EOF <<EOF <<EOF' || echo "CVE-2014-7186 vulnerable, redir_stack"
- A vulnerable system will echo the text "CVE-2014-7186 vulnerable, redir_stack".
CVE-2014-7187
CVE-2014-7187 relates to an off-by-one error, allowing out-of-bounds memory access, in the Bash parser code.[32] While working on patching Shellshock, Red Hat researcher Florian Weimer found this bug.[23]
- Testing example
Here is an example of the vulnerability, which leverages the use of multiple "done" declarations:
(for x in {1..200} ; do echo "for x$x in ; do :"; done; for x in {1..200} ; do echo done ; done) | bash || echo "CVE-2014-7187 vulnerable, word_lineno"
- A vulnerable system will echo the text "CVE-2014-7187 vulnerable, word_lineno".
|
|
|
Sep 26, 2014 | securityblog.redhat.com
Why are there four CVE assignments?
The original flaw in Bash was assigned CVE-2014-6271. Shortly after that issue went public a researcher found a similar flaw that wasn't blocked by the first fix and this was assigned CVE-2014-7169. Later, Red Hat Product Security researcher Florian Weimer found additional problems and they were assigned CVE-2014-7186 and CVE-2014-7187. It's possible that other issues will be found in the future and assigned a CVE designator even if they are blocked by the existing patches.
... ... ...
Why is Red Hat using a different patch then others?
Our patch addresses the CVE-2014-7169 issue in a much better way than the upstream patch, we wanted to make sure the issue was properly dealt with.
I have deployed web application filters to block CVE-2014-6271. Are these filters also effective against the subsequent flaws?If configured properly and applied to all relevant places, the "() {" signature will work against these additional flaws.
Does SELinux help protect against this flaw?
SELinux can help reduce the impact of some of the exploits for this issue. SELinux guru Dan Walsh has written about this in depth in his blog.
Are you aware of any new ways to exploit this issue?
Within a few hours of the first issue being public (CVE-2014-6271), various exploits were seen live, they attacked the services we identified at risk in our first post:
- from dhclient,
- CGI serving web servers,
- sshd+ForceCommand configuration,
- git repositories.
We did not see any exploits which were targeted at servers which had the first issue fixed, but were affected by the second issue. We are currently not aware of any exploits which target bash packages which have both CVE patches applied.
Why wasn't this flaw noticed sooner?
The flaws in Bash were in a quite obscure feature that was rarely used; it is not surprising that this code had not been given much attention. When the first flaw was discovered it was reported responsibly to vendors who worked over a period of under 2 weeks to address the issue.
This entry was posted in Vulnerabilities and tagged bash, CVE-2014-6271, CVE-2014-6277, CVE-2014-6278, CVE-2014-7169, CVE-2014-7186, CVE-2014-7187, shellshocked by Huzaifa Sidhpurwala. Bookmark the permalink.
|
|
|
>Update 2014-09-25 16:00 UTC
Red Hat is aware that the patch for CVE-2014-6271 is incomplete. An attacker can provide specially-crafted environment variables containing arbitrary commands that will be executed on vulnerable systems under certain conditions. The new issue has been assigned CVE-2014-7169.We are working on patches in conjunction with the upstream developers as a critical priority. For details on a workaround, please see the knowledgebase article.
Red Hat advises customers to upgrade to the version of Bash which contains the fix for CVE-2014-6271 and not wait for the patch which fixes CVE-2014-7169. CVE-2014-7169 is a less severe issue and patches for it are being worked on.
Bash or the Bourne again shell, is a UNIX like shell, which is perhaps one of the most installed utilities on any Linux system. From its creation in 1980, Bash has evolved from a simple terminal based command interpreter to many other fancy uses.
In Linux, environment variables provide a way to influence the behavior of software on the system. They typically consists of a name which has a value assigned to it. The same is true of the Bash shell. It is common for a lot of programs to run Bash shell in the background. It is often used to provide a shell to a remote user (via ssh, telnet, for example), provide a parser for CGI scripts (Apache, etc) or even provide limited command execution support (git, etc)
Coming back to the topic, the vulnerability arises from the fact that you can create environment variables with specially-crafted values before calling the Bash shell. These variables can contain code, which gets executed as soon as the shell is invoked. The name of these crafted variables does not matter, only their contents. As a result, this vulnerability is exposed in many contexts, for example:
- ForceCommand is used in sshd configs to provide limited command execution capabilities for remote users. This flaw can be used to bypass that and provide arbitrary command execution. Some Git and Subversion deployments use such restricted shells. Regular use of OpenSSH is not affected because users already have shell access.
- Apache server using mod_cgi or mod_cgid are affected if CGI scripts are either written in Bash, or spawn subshells. Such subshells are implicitly used by system/popen in C, by os.system/os.popen in Python, system/exec in PHP (when run in CGI mode), and open/system in Perl if a shell is used (which depends on the command string).
- PHP scripts executed with mod_php are not affected even if they spawn subshells.
- DHCP clients invoke shell scripts to configure the system, with values taken from a potentially malicious server. This would allow arbitrary commands to be run, typically as root, on the DHCP client machine.
- Various daemons and SUID/privileged programs may execute shell scripts with environment variable values set / influenced by the user, which would allow for arbitrary commands to be run.
- Any other application which is hooked onto a shell or runs a shell script as using Bash as the interpreter. Shell scripts which do not export variables are not vulnerable to this issue, even if they process untrusted content and store it in (unexported) shell variables and open subshells.
Like "real" programming languages, Bash has functions, though in a somewhat limited implementation, and it is possible to put these Bash functions into environment variables. This flaw is triggered when extra code is added to the end of these function definitions (inside the enivronment variable). Something like:
$ env x='() { :;}; echo vulnerable' bash -c "echo this is a test" vulnerable this is a testThe patch used to fix this flaw, ensures that no code is allowed after the end of a Bash function. So if you run the above example with the patched version of Bash, you should get an output similar to:
$ env x='() { :;}; echo vulnerable' bash -c "echo this is a test" bash: warning: x: ignoring function definition attempt bash: error importing function definition for `x' this is a testWe believe this should not affect any backward compatibility. This would, of course, affect any scripts which try to use environment variables created in the way as described above, but doing so should be considered a bad programming practice.
Red Hat has issued security advisories that fixes this issue for Red Hat Enterprise Linux. Fedora has also shipped packages that fixes this issue.
We have additional information regarding specific Red Hat products affected by this issue that can be found at https://access.redhat.com/site/solutions/1207723
Information on CentOS can be found at http://lists.centos.org/pipermail/centos/2014-September/146099.html.
|
|
|
zdnet.com
The only thing you have to fear with Shellshock, the Unix/Linux Bash security hole, is fear itself. Yes, Shellshock can serve as a highway for worms and malware to hit your Unix, Linux, and Mac servers, but you can defend against it.
The real and present danger is for servers. According to the National Institute of Standards (NIST), Shellshock scores a perfect 10 for potential impact and exploitability. Red Hat reports that the most common attack vectors are:
- httpd (Your Web server): CGI [Common-Gateway Interface] scripts are likely affected by this issue: when a CGI script is run by the web server, it uses environment variables to pass data to the script. These environment variables can be controlled by the attacker. If the CGI script calls Bash, the script could execute arbitrary code as the httpd user. mod_php, mod_perl, and mod_python do not use environment variables and we believe they are not affected.
- Secure Shell (SSH): It is not uncommon to restrict remote commands that a user can run via SSH, such as rsync or git. In these instances, this issue can be used to execute any command, not just the restricted command.
- dhclient: The Dynamic Host Configuration Protocol Client (dhclient) is used to automatically obtain network configuration information via DHCP. This client uses various environment variables and runs Bash to configure the network interface. Connecting to a malicious DHCP server could allow an attacker to run arbitrary code on the client machine.
- CUPS (Linux, Unix and Mac OS X's print server): It is believed that CUPS is affected by this issue. Various user-supplied values are stored in environment variables when cups filters are executed.
- sudo: Commands run via sudo are not affected by this issue. Sudo specifically looks for environment variables that are also functions. It could still be possible for the running command to set an environment variable that could cause a Bash child process to execute arbitrary code.
- Firefox: We do not believe Firefox can be forced to set an environment variable in a manner that would allow Bash to run arbitrary commands. It is still advisable to upgrade Bash as it is common to install various plug-ins and extensions that could allow this behavior.
- Postfix: The Postfix [mail] server will replace various characters with a ?. While the Postfix server does call Bash in a variety of ways, we do not believe an arbitrary environment variable can be set by the server. It is however possible that a filter could set environment variables.
So much for Red Hat's thoughts. Of these, the Web servers and SSH are the ones that worry me the most. The DHCP client is also troublesome, especially if, as it the case with small businesses, your external router doubles as your Internet gateway and DHCP server.
Of these, Web server attacks seem to be the most common by far. As Florian Weimer, a Red Hat security engineer, wrote: "HTTP requests to CGI scripts have been identified as the major attack vector." Attacks are being made against systems running both Linux and Mac OS X.
Jaime Blasco, labs director at AlienVault, a security management services company, ran a honeypot looking for attackers and found "several machines trying to exploit the Bash vulnerability. The majority of them are only probing to check if systems are vulnerable. On the other hand, we found two worms that are actively exploiting the vulnerability and installing a piece of malware on the system."
Other security researchers have found that the malware is the usual sort. They typically try to plant distributed denial of service (DDoS) IRC bots and attempt to guess system logins and passwords using a list of poor passwords such as 'root', 'admin', 'user', 'login', and '123456.'
So, how do you know if your servers can be attacked? First, you need to check to see if you're running a vulnerable version of Bash. To do that, run the following command from a Bash shell:
env x='() { :;}; echo vulnerable' bash -c "echo this is a test"
If you get the result:
vulnerable this is a test
Bad news, your version of Bash can be hacked. If you see:
bash: warning: x: ignoring function definition attempt bash: error importing function definition for `x' this is a test
You're good. Well, to be more exact, you're as protected as you can be at the moment.
|
|
|
26 Sep 2014 | support.novell.com
We have fixed the critical issue CVE-2014-6271 (http://support.novell.com/security/cve/CVE-2014-6271.html) with updates for all supported and LTSS code streams.
SLES 10 SP3 LTSS, SP4 LTSS, SLES 11 SP1 LTSS, SLES 11 SP2 LTSS, SLES 11 SP3, openSUSE 12.3, 13.1.
The issue CVE-2014-7169 ( http://support.novell.com/security/cve/CVE-2014-7169.html) is less severe (no trivial code execution) but will also receive fixes for above. As more patches are under discussions around the bash parser, we will wait some days to collect them to avoid a third bash update.
|
|
|
NSA has developed and distributed configuration guidance for Red Hat Enterprise Linux 5 that is currently being used throughout the government and by numerous entities as a security baseline for their Red Hat Enterprise Linux 5 systems. See also Hardening Tips for the Red Hat Enterprise Linux 5
|
|
|
Good, carefully written guide. highly recommended
This Linux Security HOWTO is intended for a technical audience, Linux system administrators, and security people in corporations and organizations that have to use commercial Linux distributions for their production environment. If you are a Linux expert then you may find familiar material here, but you will have difficulties to find documentation on various topics like restricting su access to system and shared accounts only as covered in this article, see Restricting su Access to System and Shared Accounts.
If you need to make Linux production systems compliant with various audit requirements, then this article should offer a good baseline and starting point. The main objective of this Linux Security guide is to discuss basic Linux security requirements including account policies for production systems that are being audited. This document covers various system services like SSH which are usually enabled and required on all Linux production servers. But it does not cover services or applications like Apache, Samba etc., since these applications/services are usually not needed across all Linux servers and should therefore not be installed on all systems. In fact, these applications warrant their own security HOWTO. Also, this article does not cover security features that require kernel patching. This is not an option for most companies due to vendor support issues.This Linux Security Cookbook has been tested on Red Hat Linux but should also be applicable to many other Linux distributions like Novell SUSE.
|
|
|
Just noticed where the NSA has made available two documents on hardening and secure configuration of RHEL 5. Should be interesting to read through the documents to see what they recommend. I wonder how much of this can be passed on to the Fedora community.Almost all of it can be passed on. There are great tips in there - kernel sysctl's tuning, SSH hardening, disabling coredumps, using AIDE, and disabling SUID on unneeded binaries, just to name a few. I found it a really good read,
|
|
|
22nd August 2008Last week Red Hat detected an intrusion on certain of its computer systems and took immediate action. While the investigation into the intrusion is on-going, our initial focus was to review and test the distribution channel we use with our customers, Red Hat Network (RHN) and its associated security measures. Based on these efforts, we remain highly confident that our systems and processes prevented the intrusion from compromising RHN or the content distributed via RHN and accordingly believe that customers who keep their systems updated using Red Hat Network are not at risk. We are issuing this alert primarily for those who may obtain Red Hat binary packages via channels other than those of official Red Hat subscribers.
In connection with the incident, the intruder was able to get a small number of OpenSSH packages relating only to Red Hat Enterprise Linux 4 (i386 and x86_64 architectures only) and Red Hat Enterprise Linux 5 (x86_64 architecture only) signed. As a precautionary measure, we are releasing an updated version of these packages and have published a list of the tampered packages and how to detect them.
To reiterate, our processes and efforts to date indicate that packages obtained by Red Hat Enterprise Linux subscribers via Red Hat Network are not at risk.
We have provided a shell script which lists the affected packages and can verify that none of them are installed on a system:
The script has a detached GPG signature from the Red Hat Security Response Team (key) so you can verify its integrity:
This script can be executed either as a non-root user or as root. To execute the script after downloading it and saving it to your system, run the command:
bash ./openssh-blacklist-1.0.shIf the script output includes any lines beginning with "ALERT" then a tampered package has been installed on the system. Otherwise, if no tampered packages were found, the script should produce only a single line of output beginning with the word "PASS", as shown below:
bash ./openssh-blacklist-1.0.sh PASS: no suspect packages were found on this systemThe script can also check a set of packages by passing it a list of source or binary RPM filenames. In this mode, a "PASS" or "ALERT" line will be printed for each filename passed; for example:
bash ./openssh-blacklist-1.0.sh openssh-4.3p2-16.el5.i386.rpm PASS: signature of package "openssh-4.3p2-16.el5.i386.rpm" not on blacklistRed Hat customers who discover any tampered packages, need help with running this script, or have any questions should log into the Red Hat support website and file a support ticket, call their local support center, or contact their Technical Account Manager.
|
|
|
Linux Vs. Windows: CeBIT Panelists Weigh The OS
May 28, 2004, 21 :15 UTC (6 Talkback[s]) (3388 reads)
(Other stories by Jacqueline Emigh)By Jacqueline Emigh
Linux Today CorrespondentDo Linux security exploits really belong in the same league as Windows security holes? Are OpenOffice and its derivatives actually as good as Microsoft Office? These are just a couple of the questions debated this week by a panel of experts at the CeBIT America show in New York City.
Comparing Linux and Windows security amounts to a "chicken and egg" issue, according to Kathy Ivens, an author and consultant.
Given that Linux is a more secure environment, it's tough to know whether this is because Linux is "inherently more secure," or because Windows is still the more prevalent environment, Ivens said, during a panel moderated by Paul Gillin, VP of Editorial at TechTarget.
Also during the session, Nicholas Petreley, an analyst and consultant at Evans Data, contended that regardless of the numbers of exploits per platform, Windows exploits are often much more severe. Citing materials produced by Microsoft itself, Petreley said that many of the growing population of worms targeting Windows let outside hackers "completely take over" a server.
In contrast, Linux exploits are generally more limited in scope, and more likely to lend themselves to insider attacks, Petreley suggested. One Linux exploit, for instance, permits information in Firebird servers to be overwritten.
Generally speaking, though, Windows is still easier to administer, according to several of the panelists. "That's where Linux is behind, especially in directory services," Petreley observed.
Jon "Maddog" Hall, president and executive director of Linux International, pointed to third-party tools, available from vendors such as IBM and Computer Associates (CA), for managing Linux along with MVS and Unix, for example.
"In enterprise environments, that's what (you're) looking for," said Hall. Yet, he admitted, companies need to pay for such tools.
"(Administrative) controls are a lot better (in Windows)," Ivens asserted, citing printer set-up as one example.
Meanwhile, other panelists pointed to freely available Linux tools such as Samba.
What about Linux on the desktop? OpenOffice and its derivatives lack some of the features of Microsoft Office, according to Mark Minasi, a writer and consultant
Petreley, though, argued that EI (Evermore Integrated) Office, an office suite from Evermore Software, contains a similar feature set to Microsoft Office. Unlike Microsoft Office, however, EI Office doesn't allow anti-aliasing of fonts, he acknowledged, attributing this distinction to a decision by authors of the Java-based program to reduce overhead. EI Office runs on both Linux and Windows.
OpenOffice types of suites also tend to come with fewer fonts, indicated Hall. One rather obvious reason is that some font creators charge for the fonts, according to Hall.
On an overall basis, Linux applications still lack the "fit and finish" of Windows apps, Minasi charged. To gain more traction on the desktop, Linux needs a better GUI, he insisted.
Ivens, however, argued that GUIs aren't necessarily the way to go for all applications. In fact, some database and accounting apps have actually taken performance hits from the advent of the Windows GUI.
"There's no reason to have a GUI to punch in numbers," Ivens said. She harkened back to the days when the MAS 90 accounting system was at its zenith. Back then, MAS 90 was sold in Unix and DOS flavors. "My clients loved it," according to Ivens.
Ivens would also like to see fewer features in today's office suites. Microsoft Office, she quipped, seems to be evolving under an illusion in Redmond that "everyone in the world is collaborating on a single document."
Yet most users take advantage of only a small fraction of Office features, and migration to Microsoft Office 2003 has been particularly slow, Ivens observed.
In terms of third-party desktop applications, Linux is now starting to catch up with Windows, panelists generally concurred. Quicken, for instance, is now available for Linux, said Hall.
Desktop gaming, however, is one area where Linux still lags, according to Petreley. Yet with increasing improvements to game consoles such as Game Cube, more consumers are migrating from Windows-based PC games to consoles.
On the other hand, Windows doesn't necessarily hold much of an edge when it comes to ease of installation, according to the CeBIT panelists. Many users don't know how tricky Windows can be to install, since Windows still comes pre-installed on most PCs, members of the CeBIT audience were told.
Hall said that he'll be more than happy if Linux ultimately captures 30 percent of the desktop space.
"Competition is good," he declared. Hall reasoned that, as a result, no operating system -- not even Linux -- should totally dominate any market.
|
|
|
With the release of Linux version 2.6, Linux scalability has leapt to the point where it will support deployment on 32-way SMP machines. IBM sees this, rightly in my opinion, as an opportunity to sell Linux based solutions into an area of usage from which it had previously been excluded. This means big ERP, CRM and SCM implementations (using SAP, PeopleSoft et al). It also means big database implementations and big app server implementations. This is also an area where the 64-bit implementations of Linux will deliver value.
According to Adam Jollans, who is part of IBM's Linux Marketing Strategy team, the adoption of Linux is happening most quickly in Banking, Government and Retail, followed by sectors that use scientific or engineering applications (automotive, pharmaceuticals, life sciences, education etc.) This is unusual in some respects as the Banking industry is normally an early adopter of technology whereas Government is normally a late adopter, but these two sectors appear to be driving Linux adoption along with Retail.
Government qualifies as a special case, since many governments now see in Linux the possibility of stimulating a local IT software industry and are doing what they can to stimulate the growth of Linux skills. And naturally, IBM is doing what it can to associate itself with many of these initiatives, having set up competence centres in Moscow, Beijing and Romania and offering support for Linux based government initiatives wherever it can.
IBM is also active in stimulating Linux adoption among ISVs and Business Partners, offering incentives to migrate to Linux, which vary from market development funding and marketing assistance to big discounts on IBM Linux-based software. This is not so much a new initiative, as IBM has been enabling the Linux community for many years now, just a more aggressive push than before.
IBM also has many developers working on Linux and other key Open Source projects. Currently the count is at about 500, which if you think about it, represents a large on-going investment. However, there can be little doubt that IBM is getting an adequate return, and in any event it has another axe to grind.
IBM's "On Demand" initiative will be far more likely to deliver results if a single standard operating system emerges in the coming years. As far as I can tell, this looks likely to happen and it will be the horse that IBM is so clearly backing; Linux.
|
|
|
IBM, Hewlett-Packard and Sun Microsystems, among others, are creating an imperative. Their infrastructure initiatives, entitled respectively; On Demand, Adaptive Enterprise and N1, are all quite similar and aimed at the idea of virtualising the hardware layer. The primary reason for wanting to virtualise hardware is this; in the last five years or so companies have been buying servers in an ad hoc manner, tending to deploy them on a one server per application basis.
Consequently, they assembled server farms which turn out to have an average hardware utilization of about 20 percent. This is, of course, a waste of money and, in the long run, a management headache. However there are other imperatives, particularly the idea of being able to provide infrastructure as a service - dynamically, i.e. you pay for what you use and you get what you need when you need it.
So companies, especially large companies, are very receptive to the idea of corporate computer resource that is both managed and efficient - which is what IBM, HP and Sun are talking about. However, if you talk the talk you are also going to have to walk the walk, and right now, what can be delivered doesn't amount to wall-to-wall virtualisation - or anything like it.
So the question is: How is it ever going to be delivered - given legacy systems, existing server farms and the enormous difficulty involved in relocating applications in a heterogeneous network.
Blade technology, grid computing, automatic provisioning, SANs, NAS and so forth will play a part in this, but for it to work, and work well, it will require a standard OS - and there is only one candidate - Linux.
The easiest way to see the need for a standard OS is to consider why and how TCP/IP became a standard. It didn't happen because it was the best option or because it was purpose designed to run a world-wide network with hundreds of millions of nodes (it wasn't). It happened because it was the only reasonable choice at the time. The same is now true of Linux as regards hardware virtualisation. Irrespective of its other qualities, it is the only one that fits the bill.
It qualifies because it spans so many platforms - from small devices up to IBM's zSeries mainframe. It also qualifies because, like TCP/IP, it doesn't actually belong to anyone. It runs on most chips and is rapidly becoming the developer platform of choice. So the idea is starting to emerge that you virtualise storage by the use of SANs and NAS and you virtualise server hardware by the use of Linux - thus making it feasible to switch applications from one server to another automatically, and quickly. Within this capability you can cater for failover and make highly efficient use of resources.
This doesn't solve all the problems of virtualisation - and there are many, including legacy hardware that will never run Linux and legacy applications that will never run on Linux. But this doesn't actually matter. In the short run they'll get excluded from virtualisation and in the long run, they cease to exist.
The momentum is building and Linux is set to become the standard OS for hardware virtualisation in large networks. Other OSes may eventually have to impersonate the characteristics of Linux or move aside.
|
|
|
By
Benjamin D. Thomas
1/6/2004
This article examines the process of proper Linux security management in 2004. First, a system should be hardened and patched. Next, a security routine should be established to ensure that all new vulnerabilities are addressed. Linux security should be treated as an evolving process.
Introduction As Linux continues to gain popularity in the business world, security issues are something that cannot be ignored. In 2003, several well known Linux distributors had servers compromised. In one particular case, the vulnerability was well known in advance, but most vendors took entirely too much time to release an update. Similarly, most security problems that users face are known well in advance. As with any system, security on Linux is a process. It requires full commitment and due diligence. The secret is determining your own vulnerabilities and fixing them before anything catastrophic happens.
Although Linux security is entirely in the hands of system administrators, several improvements have been made at the kernel level. With the release of kernel version 2.6, users will now be able to take advantage of the Linux Security Module allowing greater levels of security customization, modularization, and ease of management. Another thing that has changed in the past several years is that today more of us are reliant on automated software update services. Rather than download and install patches manually, it is now easier to subscribe to a trusted source and let the system manage itself. As long as the integrity of the trusted source remains strong, automated management works flawlessly. As soon as something questionable happens, it is necessary to re-evaluate.
Solve the Problem
Addressing Linux security is like solving any problem. It must be approached with a purpose and plan. If you have been using Linux and neglecting security, it is now time to face it head on. Although the task may seems daunting in the beginning, it will soon be apparent that securing a Linux system is actually very strait forward.
In general security can be summed up into several steps. First, live by the minimum necessary rule. For example, turn off all unnecessary services, remove all programs that are not being used, and only give access when it is absolutely critical to a particular job function. Taking this simplistic approach will not only increase security, but over time will make life easier. It will eventually mean less stale-accounts to remove, less software to patch, and greater system performance.
Next, keep a software inventory of all versions used. Use this information to conduct the research necessary to ensure that all have been patched appropriately. Doing this, will greatly reduce the risk of being compromised by a known vulnerability. As simple as it may sound, doing this will make the system no longer an easy target, therefore be much less likely compromised. Unless the attacker is highly motivated highly sophisticated a hardened system will not be appealing.
Because most organizations have tens to hundreds of systems to manage, living by the minimum necessary rule, and establishing a security patch baseline is not always easy. The only way to approach Linux security is by developing a detailed plan. If server roles can be modularized, it may be much easier to determine what software is actually necessary for operation. Similarly, if multiple Web servers are on the network, they should all have the same basic set of software which again makes management easier. Planning for security, rather than trying to bolt it on after implementation is the key to success.
Setup a Routine
After a security plan is established and well underway, it also necessary to have a security routine. Security patches are released daily and your organization must have a way to deal with these. Hardening a system will only ensure a high level of security a single point in time. As time moves forward and vulnerabilities are discovered and exploits are made public, the system will become more vulnerable each day. To address this, it is necessary to monitor mailing lists, subscribe to our newsletter Linux Advisory Watch, or subscribe to an automated patch management system. When evaluating Linux distributions, it is important to take into account the frequency, timeliness, and reliability of security updates. Unfortunately, some distributions have been known to only release updates every several months in inconsistent intervals. Others are very good and release patches very soon after the vulnerability is known.
Some may wish to apply security updates daily, but it is probably more reasonable to apply them weekly. Of course, exceptions should be made for very critical updates. If production servers are going to be updated, it is advisable to first try them out in a testing environment. This is to minimize any damage that a flawed patch may cause. Also, do not forget to check the MD5 checksums of all downloaded patches. This can be done easily using the command-line tool 'md5sum.' To ensure overall system integrity, it is beneficial to a tool such as tripwire.
Being the new year, it is now the best time to establish a routine. Excuses can always be made, but now is the best time to start. Determine what is necessary to keep your systems operating securely, and pick a day each week to devote to this. Time should be spent applying security patches, reviewing logs, reviewing active user accounts, and looking for anomalies. Devoting just a little time specifically security each week can make a huge difference. It is always better to address problems before they crop up.
Concluding Remarks
Security requires both dedication and commitment. 2004 can be a good year if you expect security problems and then develop specific plans to address each of them. After the basics have been addressed, now is the time to establish a routine that will ensure security is addressed on a reoccurring basis rather than waiting for problems to surface. To maintain proper Linux security, it must be a regular part of an organization's operational maintenance. Being the beginning of a new year, it is now the perfect time to establish routines that will promote greater security. Linux is a wonderful operating system and holds a huge amount of potential. Security should not be major concern as long as it is handled properly.
Benjamin Thomas is a long time contributor to
LinuxSecurity.com and EnGarde Secure Linux.
|
|
|
Open source software has surpassed Microsoft software in terms of security problems, according to an Aberdeen Group report.
"Open source software, commonly used in many versions of Linux, Unix, and network routing equipment, is now the major source of elevated security vulnerabilities for IT buyers," the report stated.
The research cited a list of advisories published by the Computer Emergency Response Team (CERT), a federally funded research and development center operated by Carnegie Mellon University.
The CERT report claims that security alerts for open source
and Linux software accounted for 16 out of the 29 advisories published during the first 10 months of 2002. During those same 10 months, only seven security problems were documented in Microsoft products.
Trojan Horses and Viruses
Microsoft applications have made significant progress in avoiding virus and Trojan horse problems, according to CERT. The number of such advisories peaked in 2001 at six, but none were posted during the first 10 months of 2002.
Virus and Trojan horse advisories for Unix, Linux and open source software went from one in 2001 to two in the first 10 months of 2002.
To fully understand these figures, it is important to understand CERT's criteria for issuing an advisory, Aberdeen Group research director and report co-author Eric Hemmendinger told NewsFactor.
For example, although several viruses that affect Microsoft products have been reported this year, such threats need to reach a certain severity level before CERT will issue an advisory in response to them, he said.
New Poster Child
"Obviously, the label of poster child for security glitches moved from Microsoft to the shoulders of open source and Linux product suppliers during 2002," the Aberdeen research stated.
Hemmendinger said the greater number of security vulnerabilities in open source was connected to problems with quality assurance testing. "While there are multiple distributors of open source products, there is no single entity responsible for quality assurance or for addressing security issues," he said.
Popular Misconception
Hemmendinger noted that the CERT findings run counter to what he sees as a popular misconception: that Microsoft software suffers the most security problems.
He said that network administrators trying to assess Microsoft versus open source platform strategies "need to set aside everything you've heard over the last year and look at what the numbers actually show. Perception does not match reality."
Rationale for Change
One reason for the decreased number of Microsoft security problems may be "the beginnings of an impact of efforts Microsoft has made to improve coding practices," Hemmendinger said.
He noted that not only has Microsoft made security a major push this year, "but there have been a number of things that have gone on [in Microsoft] over the last couple years reflecting that they know security matters, and that they had to pay attention to it."
Future of Open Source
Hemmendinger predicted even more security advisories will be released for open source products in the future, while the number of Microsoft security vulnerabilities will remain flat or decrease.
"The numbers lag the adoption," he said, explaining that as open source becomes more prevalent, problems -- and scrutiny of weaknesses -- will increase.
Apple Bit, Also
"Apple's products are now just as vulnerable, now that it is fielding an operating system with embedded Internet protocols and Unix utilities," the Aberdeen reported added.
According to the CERT list, security advisories affecting Apple's
| Linux Security Quick Reference Guide | |
| This Quick Reference Guide is intended to provide a starting point for improving the security of your system. Contained within include references to security resources around the net, tips on securing your Linux box, and general security information. | |
| [PDF] [PS] [A4 PS] [A4 PDF] | |
| Linux Security Administrator's Guide | |
| This is a document that I last made modifications to in 1998, but is still pretty relevant. Topics covered include developing a security policy, network and host security tips, process accounting, physical security, intrusion detection, files and filesystem security, encryption, kernel security, explanation of many types of exploits, links to documents on writing secure code, firewalls, and incident response. I would be very interested in hearing any comments about this document. | |
| [HTML] [PS] [DVI] [SGML] [TEXT] | |
| LinuxSecurity.com Main Documentation Resource Page | |
| This section contains documentation on how to improve the security of your Linux box, whitepapers on various security issues, newsletters, a glossary of security terms as well as publications. We've tried our best to accumulate the most relevant and up-to-date list of documentation here. | |
| [HTML] | |
| comp.os.linux.security FAQ | |
| This FAQ is intended to serve as a starting point for those new to the newsgroup, but
is also intended to be a survey of Linux security issues and tools. This FAQ is aimed at intermediate to experienced Linux users
and is intended to not only answer specific questions, but to also facilitate further learning by providing pointers other useful
security resources.
Be sure to read our interview with author Daniel Swan to learn more about this document. |
|
| [HTML] | |
| Linux Security HOWTO | |
| This document is a general overview of security issues that face the administrator of Linux systems. It covers general security philosophy and a number of specific examples of how to better secure your Linux system from intruders. Also included are pointers to security-related material and programs. | |
| [HTML] | |
| Linux Security Quick-Start Guide | |
| This document, written by Hal Burgiss, is an introductory level document that provides
the information necessary for inexperienced Linux users to secure their machine. Well-written and thorough.
Be sure to read our interview with Hal on Linux security and his document. |
|
| [HTML] [Red Hat Version] | |
| Understanding TCP/IP | |
| This Cisco whitepaper discusses the TCP/IP architecture and provides a basic reference model that explains TCP/IP terminology and describes the fundamental concepts underlying the TCP/IP protocol suite. Great document. | |
| [PDF] | |
| Securing Debian HOWTO | |
| This document describes the process of securing and hardening the default Debian installation. In addition this document just gives a overview of what you can do to increase the security of your Debian GNU/Linux installation. Many parts of this HOWTO can be transferred to other distributions. | |
| [HTML] [PDF.GZ] [TXT.GZ] | |
| Secure Programming HOWTO | |
| This paper provides a set of design and implementation guidelines for writing secure programs for Linux and Unix systems. Such programs include application programs used as viewers of remote data, CGI scripts, network servers, and setuid/setgid programs. Specific guidance for C, C++, Java, Perl, Python, and Ada95 are included. See our interview with David Wheeler on LinuxSecurity.com. | |
| [HTML] | |
| WWW Security FAQ | |
| This is the World Wide Web Security Frequently Asked Question list (FAQ). It attempts to answer some of the most frequently asked questions relating to the security implications of running a Web server and using Web browsers. | |
| [HTML] | |
| Chroot-BIND HOWTO | |
| Describes installing the BIND 9 nameserver to run in a chroot jail and as a non-root user, to provide added security and minimise the potential effects of a security compromise. | |
| [HTML] | |
| Encryption HOWTO | ||
| This document will (eventually, more or less extensively) describe all major development activities around the Linux operating system that provide encryption features to the kernel. | ||
| [HTML] | ||
| Securing-Domain HOWTO | |
| Outlines the things you will probably have to do when you want to setup a network of computers under your own domain. Covers configuration of network parameters, network services, and security settings. | |
| [HTML] | |
| VPN HOWTO | |
| This HOWTO describes how to set up a Virtual Private Network with Linux. | |
| [HTML] | |
| VPN Masquerade HOWTO | |
| How to configure a Linux firewall to masquerade IPsec-and PPTP-based Virtual Private Network traffic, allowing you to establish a VPN connection without losing the security and flexibility of your Linux firewall's internet connection and allowing you to make available a VPN server that does not have a registered internet IP address. | |
| [HTML] | |
Securing and Optimizing Linux: Red Hat Edition
This book addresses unanswered questions about Linux security and optimization in the marketplace. It is intended for a technical audience and discusses how to install a Red Hat Linux Server with all the necessary security and optimization for a high performance Linux-specific machine. It covers (in detail) several ways to configure security and optimization.
alt.2600 Hack FAQ
The purpose of this FAQ is to give you a general introduction to the topics covered in alt.2600 and #hack. General information on hacking, telephony, cellular communications, security resources, and a description of what alt.2600 actually is.
Google matched content |
[Jan 29, 2019] RHEL7 is a fine OS, the only thing it s missing is a really good init system. Published on Oct 14, 2018 | linux.slashdot.org
[Oct 15, 2018] Systemd as doord interface for cars ;-) by Nico Schottelius Published on Oct 15, 2018 | blog.ungleich.ch
rhel5-guide-i731 NSA RHEL5 Hardening guide
Restricting su Access to System and Shared Accounts[PDF] Hardening Red Hat Enterprise Linux 5
Hardening a Linux Installation
Red Hat Enterprise Linux 4. Red Hat SELinux Guide. Copyright © 2005 Red Hat, Inc. ISBN: N/A. Table of Contents; Introduction to the Red Hat SELinux Guide ...
www.redhat.com/docs/manuals/ enterprise/RHEL-4-Manual/selinux-guide/ - 11k
Installing and configuring OpenLDAP for RedHat Enterprise Linux 3
Installing and configuring OpenLDAP for RedHat Enterprise Linux3 ... It is highly recommended that OS level Security Hardening be applied to all LDAP ...
web.singnet.com.sg/.../ Installing%20and%20configuring%20OpenLDAP%20for%
CERT Guides
- CERT-In Security Guidelines CISG-2005-03
(31st December 2005)
Securing Home Computers
- CERT-In Security Guidelines CISG-2005-02 (18th May 2005) RedHat Enterprise Linux 3.0 Minimization and Hardening Guidelines
- CERT-In Security Guidelines CISG-2004-04 (17th August 2004) Web Server Security Guidelines
- CERT-In Security Guidelines CISG-2004-03 (28th June 2004) Implementation of Central Logging Server using syslog-ng
- CERT-In Security Guidelines CISG-2004-02 (11th June 2004) Cisco Router Security Best Practices
- CERT-In Security Guidelines CISG-2004-01 (4th June 2004) Securing Red Hat Linux 9.0 as a Web Server
- CERT-In Security Guidelines CISG-2003-08 (21st October 2003) Cisco Router Security Guidelines
- CERT-In Security Guidelines CISG-2003-07 (October 21, 2003) Database Server Security Guidelines
- CERT-In Security Guidelines CISG-2003-06 (25th August 2003) IDS - Intrusion Detection System
- CERT-In Security Guidelines CISG-2003-05 (13th August 2003) Anti Virus Policy & Best Practices
Society
Groupthink : Two Party System as Polyarchy : Corruption of Regulators : Bureaucracies : Understanding Micromanagers and Control Freaks : Toxic Managers : Harvard Mafia : Diplomatic Communication : Surviving a Bad Performance Review : Insufficient Retirement Funds as Immanent Problem of Neoliberal Regime : PseudoScience : Who Rules America : Neoliberalism : The Iron Law of Oligarchy : Libertarian Philosophy
Quotes
War and Peace : Skeptical Finance : John Kenneth Galbraith :Talleyrand : Oscar Wilde : Otto Von Bismarck : Keynes : George Carlin : Skeptics : Propaganda : SE quotes : Language Design and Programming Quotes : Random IT-related quotes : Somerset Maugham : Marcus Aurelius : Kurt Vonnegut : Eric Hoffer : Winston Churchill : Napoleon Bonaparte : Ambrose Bierce : Bernard Shaw : Mark Twain Quotes
Bulletin:
Vol 25, No.12 (December, 2013) Rational Fools vs. Efficient Crooks The efficient markets hypothesis : Political Skeptic Bulletin, 2013 : Unemployment Bulletin, 2010 : Vol 23, No.10 (October, 2011) An observation about corporate security departments : Slightly Skeptical Euromaydan Chronicles, June 2014 : Greenspan legacy bulletin, 2008 : Vol 25, No.10 (October, 2013) Cryptolocker Trojan (Win32/Crilock.A) : Vol 25, No.08 (August, 2013) Cloud providers as intelligence collection hubs : Financial Humor Bulletin, 2010 : Inequality Bulletin, 2009 : Financial Humor Bulletin, 2008 : Copyleft Problems Bulletin, 2004 : Financial Humor Bulletin, 2011 : Energy Bulletin, 2010 : Malware Protection Bulletin, 2010 : Vol 26, No.1 (January, 2013) Object-Oriented Cult : Political Skeptic Bulletin, 2011 : Vol 23, No.11 (November, 2011) Softpanorama classification of sysadmin horror stories : Vol 25, No.05 (May, 2013) Corporate bullshit as a communication method : Vol 25, No.06 (June, 2013) A Note on the Relationship of Brooks Law and Conway Law
History:
Fifty glorious years (1950-2000): the triumph of the US computer engineering : Donald Knuth : TAoCP and its Influence of Computer Science : Richard Stallman : Linus Torvalds : Larry Wall : John K. Ousterhout : CTSS : Multix OS Unix History : Unix shell history : VI editor : History of pipes concept : Solaris : MS DOS : Programming Languages History : PL/1 : Simula 67 : C : History of GCC development : Scripting Languages : Perl history : OS History : Mail : DNS : SSH : CPU Instruction Sets : SPARC systems 1987-2006 : Norton Commander : Norton Utilities : Norton Ghost : Frontpage history : Malware Defense History : GNU Screen : OSS early history
Classic books:
The Peter Principle : Parkinson Law : 1984 : The Mythical Man-Month : How to Solve It by George Polya : The Art of Computer Programming : The Elements of Programming Style : The Unix Hater’s Handbook : The Jargon file : The True Believer : Programming Pearls : The Good Soldier Svejk : The Power Elite
Most popular humor pages:
Manifest of the Softpanorama IT Slacker Society : Ten Commandments of the IT Slackers Society : Computer Humor Collection : BSD Logo Story : The Cuckoo's Egg : IT Slang : C++ Humor : ARE YOU A BBS ADDICT? : The Perl Purity Test : Object oriented programmers of all nations : Financial Humor : Financial Humor Bulletin, 2008 : Financial Humor Bulletin, 2010 : The Most Comprehensive Collection of Editor-related Humor : Programming Language Humor : Goldman Sachs related humor : Greenspan humor : C Humor : Scripting Humor : Real Programmers Humor : Web Humor : GPL-related Humor : OFM Humor : Politically Incorrect Humor : IDS Humor : "Linux Sucks" Humor : Russian Musical Humor : Best Russian Programmer Humor : Microsoft plans to buy Catholic Church : Richard Stallman Related Humor : Admin Humor : Perl-related Humor : Linus Torvalds Related humor : PseudoScience Related Humor : Networking Humor : Shell Humor : Financial Humor Bulletin, 2011 : Financial Humor Bulletin, 2012 : Financial Humor Bulletin, 2013 : Java Humor : Software Engineering Humor : Sun Solaris Related Humor : Education Humor : IBM Humor : Assembler-related Humor : VIM Humor : Computer Viruses Humor : Bright tomorrow is rescheduled to a day after tomorrow : Classic Computer Humor
The Last but not Least Technology is dominated by two types of people: those who understand what they do not manage and those who manage what they do not understand ~Archibald Putt. Ph.D
Copyright © 1996-2021 by Softpanorama Society. www.softpanorama.org was initially created as a service to the (now defunct) UN Sustainable Development Networking Programme (SDNP) without any remuneration. This document is an industrial compilation designed and created exclusively for educational use and is distributed under the Softpanorama Content License. Original materials copyright belong to respective owners. Quotes are made for educational purposes only in compliance with the fair use doctrine.
FAIR USE NOTICE This site contains copyrighted material the use of which has not always been specifically authorized by the copyright owner. We are making such material available to advance understanding of computer science, IT technology, economic, scientific, and social issues. We believe this constitutes a 'fair use' of any such copyrighted material as provided by section 107 of the US Copyright Law according to which such material can be distributed without profit exclusively for research and educational purposes.
This is a Spartan WHYFF (We Help You For Free) site written by people for whom English is not a native language. Grammar and spelling errors should be expected. The site contain some broken links as it develops like a living tree...
|
|
You can use PayPal to to buy a cup of coffee for authors of this site |
Disclaimer:
The statements, views and opinions presented on this web page are those of the author (or referenced source) and are not endorsed by, nor do they necessarily reflect, the opinions of the Softpanorama society. We do not warrant the correctness of the information provided or its fitness for any purpose. The site uses AdSense so you need to be aware of Google privacy policy. You you do not want to be tracked by Google please disable Javascript for this site. This site is perfectly usable without Javascript.
Created Jan 2, 2005. Last modified: February 02, 2021
