Slashdot Mirror

you need root privileges to bind to port 80

Common sense would indicate that in that scenario you either

• 1. Get the socket as early as possible in startup then setuid(2) yourself to a user with lower privileges (and chroot yourself, while you are at it) before answering any requests
• 2. Failing that, run on a high numbered port and have iptables forward you traffic from 80, which is a specific instance of the more general strategy: run as little code as possible at high privilege

What's not an answer is "run the actual process as root while serving user requests". It's shocking that this is even considered remotely like a possible solution.

What's doubly galling is that there is a loooong unix history of applications that require far more intrusive privileges using both or these techniques -- either getting what they need and immediately dropping to the position of least privilege or using a small shim or utility that runs in a high-privileged space and communicates with the rest of the service via IPC. So it's not like they couldn't draw on those examples or literally just copy-pasta DJB's code.

What's triply galling is that the fix doesn't actually appear to mentioned fixing any of this, just patching this one vulnerability.

It is a dumb idea because like all your security measures are easily circumvented and provides no real security. Also if I don't trust your program I wouldn't trust its self check either no matter how many times it performs it.

It doesn't matter if I have done better, I have but then unlike you I don't work on toy problems, as we were discussing the poor quality of your work.

How come I can't find any official documentation for the hosts file stating hosts does port filtering as you claim? Not here, not here, and not here (says it follows the BSD format in previous links though). That doesn't mean that someone didn't create some stupid 3rd party program that does such a thing as I have seen lots of stupid shit added to the hosts file by programs and sysadmis. By doing that one could also make just as valid claim that hosts is also a Turing complete programming language too but no one makes that claim because it is fucking stupid just like yours.

So they rejected a simplistic idea because you weren't persuasive enough to convince them to accept your code. Either it was really dumb or your code was shitty.

Must be hard being constantly shown to be a loser. You never learn which is why so few people effort post with you and thus it is understandable why they just make fun of you.

"It's still not clear exactly how Game Mode will improve gaming performance, but it's likely that Windows 10 will simply suppress system processes"

Do you mean like renice does it on a Linux system.

> t waiting forever to mount the NFS shares.

If you're not dependent on the NFS shares for live daemons, do put them in autofs based automounts. That will let the rest of the boot procedure continue.

And yes, indeed, the full architecture of starting networks with systemd has become a large, complex, and fragile edifice, completely undesirable for stable servers. The strange new symlink replacing /etc/resolv.conf contributes to the confusion, described atat http://man7.org/linux/man-page...

I thought this was what sendfile(2) did in the case of file to socket. Maybe everything is less optimized than I thought, but I assumed that would end up just mapping the harddrive's DMA read into the NIC's DMA out buffer. Saturating IO lines is a job for the uncore of the CPU and the IO devices: it shouldn't significantly load any of the cores unless you are doing it wrong.

The solution is to use /dev/urandom, but only after verifying that the pool has some entropy. Ideally, it would be nice to have an API that allows you to find out how many total bits of entropy have been gathered by the system, regardless of how many remain in the pool at any given point in time. If the system has managed to accumulate a few hundred bits, just use /dev/urandom and get on with life. If it hasn't, use /dev/random and block.

The solution is to use /dev/urandom, but only after verifying that the pool has some entropy. Ideally, it would be nice to have an API that allows you to find out how many total bits of entropy have been gathered by the system, regardless of how many remain in the pool at any given point in time. If the system has managed to accumulate a few hundred bits, just use /dev/urandom and get on with life. If it hasn't, use /dev/random and block.

You could build what you are asking for by using the new (since v3.17 kernel) getrandom() syscall. See the part about emulating getentropy for determining if you've ever had up to 256 bits entropy in its man page for implementing your API suggestion...

"Linux has already removed the reason of needing VM's for running your applications thanks to the control groups kernel feature."

That doesn't work with many bits of my software. To run multiple worlds in the game I'm creating, I need multiple separate server VMs with their own IP addresses for server linking and physical separation of game content. I can't just run the server application multiple times in the same instance. The game engine software was not designed to operate like that.

Linux cgroups can give each container its own interface, with it's own IP address, and also lets you give each container it's own file system. See the man page

Basically there's no proof /dev/urandom is less safe than /dev/random - there have been no published results concerning it, and as it internally mixes in data from SHA-1 of entropy coming from random events, and known attacks against SHA-1 aren't very good, and that's before taking into consideration that we're mixing those hashes in well. There's a pretty good reason all the attacks come from lack of entropy, but as soon as you get a bit - you're set.

That said, if you have a source of random information you want to add, you can simply write to /dev/random - that mixes in a transformation on SHA-1 on your data - and adds randomness. Try, for instance, random from your network, lower bits of CPU load / temperature / RDTSC. This gets XORed in, so you can only add to the entropy (random^predictable is random).

Also, there's an ioctl you can use on /dev/random - RNDGETENTCNT - to see how much entropy your system currently has, if you want to play around with it a bit.

For the interested: Understanding-And-Managing-Entropy-Usage Whitepaper Black Hat whitepaper.

So it seems this is the classic problem that (Linux) programmers are told to use /dev/urandom (which never blocks) and some programs are doing so at system startup thus there's the opportunity for there to be "insufficient" randomness because not enough entropy has been gathered at that point in time. In short: using /dev/urandom is OK but if you are using it for security purposes you should only do it after /dev/random would have stopped blocking for a given amount of data for the first time since system startup (but there's no easy way to determine this on Linux). Or is there? Since the v3.17 kernel there is the getrandom syscall which has the beahviour that if /dev/urandom has never been "initialised" it will block (or can be made to fail right away by using flags). More about the introduction of the Linux getrandom syscall can be read on the always good LWN. And yes the BSD's had defences against this type situation first :-)

So this is bad for Linux systems that make security related "things" that depend on randomness early in startup but there may be mild mitigations in real life. If the security material is regenerated at a later point after boot there may be enough entropy around. If the the system is rebooted but preserves entropy from the last boot this may be mitigated for random material generated in subsequent boots (so long as the material was generated after the randomness was reseeded). If entropy preservation never takes place then regeneration won't help early boot programs. If the material based on the randomness is never regenerated then again this doesn't help. If you take a VM image and the entropy seed isn't reset then you've stymied yourself as the system believe it has entropy that it really doesn't.

That's not systemd. You should read the man page for fsck.xfs ( http://man7.org/linux/man-page...) which recommends you use xfs_repair.

And you can easily boot if a single non-boot partition is corrupted.

On what part did you need a prof ?

Debian package dependencies will show you that initscripts depend on sysv-rc (or file-rc) to boot the machine. Without sysv-rc, initscripts are just simple scripts that will not magically run at the boot of your machine.

If a kernel provides the features required by systemd, aside of a compatibility layer, what could technically prevent systemd to run on an other platform? Maybe the lack of motivation, ok, but from the technical point of view?

http://man7.org/linux/man-page...
I let you the joy to click on each link and to read the "CONFORMING TO" section to count how many time you find the indication "Linux specific". Just a few of them as example: pivot_root, ppoll, remap_file_pages, removexattr, restart_syscall, timerfd_create, futex.

Their reasons involve context switching and interprocess communications. Context switching has got to happen (unless they run IE in kernel space) so just get it over with. Interproces communication has always been a weakness in Microsoft systems. Since day one. Multitasking OSs are here, folks. Get over DOS.

The bug here affects the HTTP server side, not IE.

And in HTTP servers, there are LOT of context switches - in basic static file handling mode, you read a file (syscall to read file), then you write it to a socket (syscall to write to socket). in effect, a webserver is just copying from two file handles, and incurring a kernel-usermode transistion twice every round.

Add in a moderately busy webserver and you could be spending significant amounts of time just switching between modes.

Using larger buffers helps, but if your site consists of lots of little files, it's still the bottleneck.

Linux has similar functionality - see sendfile(2) and splice(2), among other commands to actually manipulate in-kernel memory buffers.

In fact, doing it in the kernel has an added bonus - if you support zero-copy, no copies are made rather than potentially having to copy to/from userspace (more overhead).

Of course, in the Linux model, all the processing happens in user made and only the tedious file copying is accelerated which ups security.

Their reasons involve context switching and interprocess communications. Context switching has got to happen (unless they run IE in kernel space) so just get it over with. Interproces communication has always been a weakness in Microsoft systems. Since day one. Multitasking OSs are here, folks. Get over DOS.

The bug here affects the HTTP server side, not IE.

And in HTTP servers, there are LOT of context switches - in basic static file handling mode, you read a file (syscall to read file), then you write it to a socket (syscall to write to socket). in effect, a webserver is just copying from two file handles, and incurring a kernel-usermode transistion twice every round.

Add in a moderately busy webserver and you could be spending significant amounts of time just switching between modes.

Using larger buffers helps, but if your site consists of lots of little files, it's still the bottleneck.

Linux has similar functionality - see sendfile(2) and splice(2), among other commands to actually manipulate in-kernel memory buffers.

In fact, doing it in the kernel has an added bonus - if you support zero-copy, no copies are made rather than potentially having to copy to/from userspace (more overhead).

Of course, in the Linux model, all the processing happens in user made and only the tedious file copying is accelerated which ups security.

The linux seccomp feature provides application sandboxing. Chrome uses it to sandbox tabs from each other and native plugins from the rest of the system.

Seccomp is accessed through the seccomp (2) system call. The SECCOMP_FILTER_FLAG_TSYNC flag is an option to seccomp (2) that transparently synchronises the effect of the call across all sandboxed threads.

i would have used POSIX shared memory Queues but the implementation sucks: it is not possible to identify the shared memory blocks after they have been created so that they may be deleted. i checked the linux kernel source: there is no "directory listing" function supplied and i have no idea how you would even mount the IPC subsystem in order to list what's been created, anyway.

ipcs

But don't use IPC shared memory. Use mmap.

One reason why systemd simply routs any opposition is, that when people actually study it, they find that is has awesome new features and solve so many of the sysvinit shortcomings. From terminating services correctly http://0pointer.de/blog/projec...
to actually tracking and supervising all running processes http://0pointer.de/blog/projec...

And because of its design, it also offer superior security features, because as PID1 it can hook into advanced kernel features like "kernel capabilities" http://man7.org/linux/man-page... and "cgroup", and soon, also kdbus. Systemd works as a Linux plumbing layer, making all these features available for end users and distro maintainers, and making them easy to use by just adding simple keywords into a text config file.

Systemd is also a cross distro comparability layer; that means upstream projects can develop against systemd, and be sure it works across many different distros. It is easy to develop DE developers to make a GUI for setting networks or NTP/time or keyboard layout etc, on a systemd OS. On non-systemd distros, everything is scattered and fragmented, making it impossible to do.

The end result is, that all new development will be done with systemd. And because people like you think that nothing needs to be changed, the non-system distros will remain utterly fragmented and unsupported from upstream projects.

The bottom line is, that if people want to use non-systemd distros in the future, they better start getting off their couches and start develop an alternative. Not only do they need to maintain sysvinit infrastructure now that the "big boys" like Red Hat and Debian and Suse and Ubuntu are converting to systemd and therefore drops sysvinit/upstart development, but also extend the present infrastructure to deal with eg. safely using rootless X. They also ought to organize to help upstream projects like KDE and Gnome, by making a similar compatibility layer that work across the few remaining non-systemd distros.

I have always admired RH for it's feature set and pursuit of enterprise-related features.
I do however have one gripe: All the config files are in the wrong place!
This isn't a real complaint, more akin to a whine. I have been using Debian for too many years on far too many servers; my muscle memory demands that the config files that I need to edit be located in the same place across distros.
Does anybody know why there is such a difference in file locations? /etc/network/interfaces
vs /etc/sysconfig/network/networking/where/are/the/damn/config/files

I think the differences are just the normal fragmentation between different distros, with everyone having their own idea of the "correct" place to put the config files. The systemd project is trying to establish a cross distro standard for some of the important config files, making it easier for upstream projects to know where e.g. /etc/os-release is (on non-systemd distros it can be "hidden" almost everywhere).

Systemd is the most important new feature of RHEL 7, since the core of the OS now have been making a huge leap forward in security and reliability regarding processes and deamons. It is now a piece of cake to utilize advanced kernel features like "capabilities" http://man7.org/linux/man-page... and "cgroup" https://www.kernel.org/doc/Doc...

All major distros are about to change to "systemd"; Red Hat, Suse, Ubuntu, Debian. Their derivatives like CentOS, Sci-Linux, Fedora etc. are also changing to systemd, so in a few years, systemd will simply be the new standard toolbox to maintain and run Linux distros, and part of the new future Linux development stack; systemd, Wayland, cgroups and kdbus.

So every Linux System Administrator who have been to procrastinating regarding learning systemd, better start reading up on the subject. A good place to start is : http://www.freedesktop.org/wik...

Some people are offended by my use of the term "ffs", and that's fine, they are right to be offended, and I'm being offensive here for a reason.

Bloody hackers...

Yes, it depends on how it was allocated. glibc uses sbrk for small allocations (as you said, under 128 KB) and mmap for larger ones. It's actually interesting to read the mallopt man page. It seems to be glibc-only, but it lets you tune all the settings we're talking about, and then some. In any case, small allocations are the big problem, because they're put in the data segment and the data segment can't be shrunk past any data still allocated, so fragmentation means glibc can't use sbrk to shrink it again (at least past the point it's fragmented at). If all a program does is small allocations, and it fragments a lot, then the memory usage of the program wouldn't really go down. Of course, it's worth noting that M_TRIM_THRESHOLD is, by default, 128 KB, so freed memory won't always be returned immediately. You can also change M_MMAP_THRESHOLD to control what size allocation will be done on the data segment and with mmap.

For large amounts, yes, glibc will mmap them and munmap them when freed. I had forgotten, though, that Firefox switched to jemalloc. It seems like jemalloc never uses sbrk, and it considers "large" allocations (large enough to allocate a dedicated block) 4 KB instead of 128 KB. It also uses multiple arenas, which seems like it would complicate things even more. I don't know if using jemalloc helps guard against memory fragmentation or not, but its allocation strategy seems sane. At the very least, some pages should be able to be returned, even if they're one of the older pages, which should help a bit. With sbrk in glibc and Windows using the heap, only the most recently allocated memory (and the freed memory before it, until it hits a still-in-use point) can be freed, but that doesn't seem to apply to jemalloc, as long as the freed memory makes up a whole page.

Of course, with Windows, they don't reveal everything about it as it's proprietary, but it does seem like memory is always allocated on the heap, and the memory will always get returned (perhaps except in cases of extreme fragmentation) eventually, but by no means immediately (in case the program wants to use it again). A program can choose to use a Windows-specific function to return it right away (_heapmin). _heapmin won't return things that are below blocks on the heap that are still allocated, though, so fragmentation is still a big issue.

I can understand why a process might want to free memory but keep it around for later allocations (and Firefox may very well tweak jemalloc to do it) but with virtual memory, there's no guarantee the first allocation was contiguous anyway. I think it would be better for the process to return memory so other things can use it, and maybe keep a small amount handy, but not everything that's been freed so far.

Also, I apologize if my post came off as rude. I re-read it later and it seemed rude to me, which was absolutely not my intention. As a programmer, I don't strictly need to know how the memory allocator works (as long as it works), but I find it extremely interesting, and knowing how things happen makes it easier to prevent memory fragmentation, so I think people should know, even if for no other reason than it's quite interesting.

For more information about the book, including a detailed table of contents, index, preface, and sample chapters, see my website for the book at http://man7.org/tlpi/.