Weekly Edition
Return to the Security page
| |||||||||||||
Security quotes of the week
Consider disabling SELinux and auditing. We recommend to leave SELinux on, for security reasons, but truth be told you can save 100ms of your boot if you disable it. Use selinux=0 on the kernel cmdline.
-- Lennart Poettering
I operate a ~10k botnet using a ZeuS software I modified myself, including
IRC, DDoS and bitcoin mining (13GH/s - 20GH/s atm). Everything operating
tru TOR hidden service so no feds will take my servers down. (Don't worry,
traffic intensive stuff is not tru TOR and the bots work as relays too,
enchancing your TOR experience!)
-- "throwaway236236"
in a reddit "Ask me anything"
When I got to the orthopedist’s office a few days later, I gave the receptionist the CD, which she promptly read into the medical records computer and returned to me. It occurred to me that the risk taken in reading a CD or other media from an unknown source is pretty substantial, something we’ve known in the security world for decades but has not filtered well into other fields. On the other hand, every time I’m on a conference program committee I open PDFs from people I may never have heard of, so it’s not as if I’m immune from this risk myself.
-- Jeremy EpsteinWhen I got home, I read the CD on my Mac laptop, and discovered that it has an autorun.INF file to start the application that reads the x-ray data files. I don’t know whether the doctor’s office disables AutoRun on their computers; undoubtedly some doctors do and others don’t. And even if the doctors’ computers have disabled AutoRun and don’t use the software on the CD to view the test results, how secure are they against data-driven attacks, such as we saw a number of years ago against JPEG files in browsers? (Log in to post comments)
Security quotes of the week Posted May 17, 2012 11:08 UTC (Thu) by epa (subscriber, #39769) [Link]
Why not let the machine boot and enable SELinux afterwards, while waiting at the login prompt?
Security quotes of the week Posted May 17, 2012 11:26 UTC (Thu) by BlueLightning (subscriber, #38978) [Link] Why not let the machine boot and enable SELinux afterwards, while waiting at the login prompt? AFAIK if any files are created during the boot process without SELinux enabled, the result will be that the files will not have the proper security descriptors. Leaving aside that this would provide an unsecured window during boot where restrictions wouldn't be enforced...
Security quotes of the week Posted May 17, 2012 19:34 UTC (Thu) by nix (subscriber, #2304) [Link]
And how surprising, after saying 'the journal will never replace syslog', we now see Lennart recommending disabling syslogd in some cases, because the journal is just as good (even though many of us have explained at tedious length just how it isn't).
Anyone willing to place a bet for how long it will be before systemd starts recommending, then requiring, the disabling of syslogd?
Security quotes of the week Posted May 17, 2012 19:58 UTC (Thu) by tcourbon (subscriber, #60669) [Link]
Then, if that doesn't suits you for whatever reason(s) you may find, all you may have do to get rid of systemd is :
- switch to plain old sysvinit - switch to upstart - start developing your very own init system
Your choice. And I pretty sure the true number of choices for anyone who does not want to run systemd is ten time larger.
(Sorry for the bad English...)
Security quotes of the week Posted May 18, 2012 7:50 UTC (Fri) by spaetz (subscriber, #32870) [Link]
> Then, if that doesn't suits you for whatever reason(s) you may find, all you may have do to get rid of systemd is :
You might have forgotten that independent udev, the official successor of devfs has already been termed obsolete technology (or was it infrastructure?) by systemd developers. So if you still want your /dev it *might* become harder and harder to use any other init system.
Not that I think systemd is not good, technology wise. But it is using pretty obvious "salami tactics" to make itself unavoidable.
Security quotes of the week Posted May 18, 2012 16:34 UTC (Fri) by vonbrand (subscriber, #4458) [Link] No, they didn't deprecate udev at all. They integrated the source of udev into systemd, as systemd needs coordination with it. It is still (and has been promised to stay for the foreseable future) independent.
Security quotes of the week Posted May 18, 2012 18:00 UTC (Fri) by dlang (✭ supporter ✭, #313) [Link]
except that LP recently blasted Mark Shuttlesworth for not switching Ubuntu to use systemd and instead sticking with a "depreciated" and "obsolete" stand-alone udev.
that doesn't sound like it matches the promise to have it remain independent.
Security quotes of the week Posted May 18, 2012 18:05 UTC (Fri) by Cyberax (✭ supporter ✭, #52523) [Link]
Except that udev will be maintained for the foreseeable future. So?
Security quotes of the week Posted May 18, 2012 18:38 UTC (Fri) by dlang (✭ supporter ✭, #313) [Link]
it depends on how you define 'maintained'
If you define it as 'if you use systemd, systemd includes what used to be udev functionality' then yes, it will be maintained for the foreseeable future.
However if you define it as 'you will be able to continue to use udev as more or less the way you did before the meger into systemd' then the fact that systemd developers are calling the use of udev without systemd depreciated, obsolete, and unsupported then I wouldn't call that continuing to maintain it.
Security quotes of the week Posted May 18, 2012 18:41 UTC (Fri) by Cyberax (✭ supporter ✭, #52523) [Link]
They've explicitly stated that the stand-alone udev will be supported, maintained and developed for the foreseeable future.
Security quotes of the week Posted May 18, 2012 19:41 UTC (Fri) by apoelstra (subscriber, #75205) [Link]
I've never heard talk of it being obsolete, except in that posting by LP, so I think he was just being dramatic.
Security quotes of the week Posted May 17, 2012 20:01 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link]
Probably not in the next 5 years.
And yes, you most probably don't need most of syslogd features on a notebook/netbook type systems. And journald right now produces "pixel perfect" syslogd output.
Security quotes of the week Posted May 22, 2012 10:18 UTC (Tue) by ssam (subscriber, #46587) [Link]
LP makes something faster and more featureful than syslog. says you can keep using syslog. and you are cross when he points out that syslog is slowing down your computer? thats the point.
if your distro decides thats fast and new is better than old and slow, and you disagree then maybe you are using the wrong distro for your needs.
Security quotes of the week Posted May 22, 2012 13:17 UTC (Tue) by nix (subscriber, #2304) [Link]
I'm not using a distro at all, because I think that stability is paramount but *also* need to use some bleeding-edge stuff (mostly toolchain stuff). Which means that every wacko idea Lennart comes up with, I have to track in case it might be useful.
But, more featureful? Sorry, I'm using syslog-ng. The journal is *enormously* less flexible than syslog-ng, and I'm not running a log farm that needs to log a million messages a second so performance is not that crucial for me. Not that syslog-ng has a problem with performance either. Also I don't want to lose my logs merely because I choose to use a different init system.
Also I'm logging over the network, which last I heard the journal doesn't support, which makes its claims of high performance bizarre because next to nobody needs high logging performance on a single host. But that's not what 'high performance' seems to mean in the journal world: apparently the only performance attribute which matters is boot time. Now I boot my systems once every few weeks. I don't much care about boot time, and 80% of my boot time is spent in the BIOS as it is so no matter what anyone does my systems will be booting slowly. I can see how boot time matters if you're using a tiny tablet or something, but not everyone is using tablets or laptops, even today.
So as far as I can see the journal provides me with a bit of useful security functionality (coming to a syslog daemon near you soon, perhaps) combined with boot time improvements I don't need, a massive reduction in functionality and a wholly unnecessary tie to a fantastically involved and recomplicated init system which is taking over more of the system every day -- and making me less and less desirous of switching to it as it does, because who knows what the heck it'll take over next?
I liked the idea of systemd when it was just a much better init. Now it's a better init and cron and session manager and daemonize() and syslogd and who knows what the hell else -- I stopped keeping track -- there's no *way* I'm going anywhere near it. Boot-critical subsystems with feature creep this severe scare the hell out of me.
I *liked* PulseAudio. It didn't have feature creep. It knew what it did and it did it much better than anything else out there. systemd? I have no idea *what* it's for anymore, other than 'everything critical to system function in one basket ready to drop'. It gives me kitchen-sink fear, and as an Emacs user I'm almost immune to that.
Security quotes of the week Posted May 22, 2012 17:44 UTC (Tue) by Cyberax (✭ supporter ✭, #52523) [Link]
You can run syslog[-ng] along with the Journal. It's supported and it JustWorks.
Yet systemd's integration with logging is massively nice: http://0pointer.de/blog/projects/systemctl-journal.html
It's really of the "Why didn't we already do this 15 years ago?" kind.
Security quotes of the week Posted May 24, 2012 0:22 UTC (Thu) by nix (subscriber, #2304) [Link]
Yes, it's supported. Now. I no longer trust that things that are supported now will remain supported. There have been too many cases of things supported by Lennart's stuff suddenly becoming deprecated without warning, and I'm not willing to trust system-critical components that exhibit that sort of fragility and lack of back-compatibility.
Security quotes of the week Posted May 24, 2012 16:56 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link]
"Too many cases"?
Currently that number is exactly 1. The full list of abandoned projects is:
Which was obsoleted by systemd and had its maintenance passed to another developer in an orderly fashion.
udev is going to be supported well into 2020 at least because it's used in RHELs.
Security quotes of the week Posted May 28, 2012 13:37 UTC (Mon) by nix (subscriber, #2304) [Link]
Other replaced projects, or projects whose replacement has been mooted, include cron, syslogd... it's true that those projects still exist for people not using systemd, but if you're using systemd all of a sudden you had to consider whether your syslogd (or whatever) was compatible with systemd in ways that you didn't have to before. And this keeps happening. Disruptive change after disruptive change.
Security quotes of the week Posted May 28, 2012 13:39 UTC (Mon) by nix (subscriber, #2304) [Link]
To reiterate: I don't think Lennart is wrong to work on systemd. I think systemd is almost certainly better than what it replaces (God knows that's not hard, sysvinit is awful and Lennart's code is rarely awful). It's just too scope-creepy for *me* to be comfortable using. I've seen too many systems with this degree of scope creep flame out and leave all sorts of chaos behind: even if systemd never flames out that would still cost me a degree of peace of mind, were I using it.
Security quotes of the week Posted May 28, 2012 14:38 UTC (Mon) by Cyberax (✭ supporter ✭, #52523) [Link]
Again, systemd is extremely careful to preserve compatibility with syslog and other daemons. Your existing infrastructure can remain totally unchanged.
Yes, it might be argued that systemd has too much scope. But this argument is clearly subjective.
Security quotes of the week Posted May 24, 2012 12:06 UTC (Thu) by ovitters (subscriber, #27950) [Link]
You're not even using a distribution? Damn..
Security quotes of the week Posted May 25, 2012 14:24 UTC (Fri) by TRauMa (guest, #16483) [Link]
Some people can tolerate all the pain in the world if it is self inflicted, but when the world deals them even a minor blow they cannot sleep until it is avenged. It's the sysadmin flavor of NIH.
Security quotes of the week Posted May 28, 2012 13:35 UTC (Mon) by nix (subscriber, #2304) [Link]
Nah. I'm just a flaming control freak regarding my own systems. (Also, this way, if something goes wrong I can generally fix it very fast indeed, and my job depends on me knowing how the guts of the system works.)
The admin overhead once you get things spinning properly is minimal, until someone throws a major change like this into the works. systemd et al is clearly better than init, but... I just can't trust that it won't keep expanding in scope until it's eaten things I rely on. :( Scope creep is a terrible thing, and systemd seems to have a really serious case of it.
|
|||||||||||||