c0t0d0s0.org

Canaries and other techniques that leverage volatiles do not prevent an overflow; they just try to cope with the consequences of an overflow which has happened. (This is why they're generally lumped together as "mitigation".) The canary tries to detect the case of an overflow which overwrites the return address in a stack frame. Data Execution Prevention (DEP) takes this idea a step further, it assumes that the return address has been overwritten and followed, and it restricts the areas where execution could jump. ASLR is yet another step further: it "shuffles" the areas where execution is allowed.

More specifically, stack canaries work by modifying every function's prologue and epilogue regions to place and check a value on the stack respectively. As such, if a stack buffer is overwritten during a memory copy operation, the error is noticed before execution returns from the copy function. When this happens, an exception is raised, which is passed back up the exception handler hierarchy until it finally hits the OS's default exception handler. If you can overwrite an existing exception handler structure in the stack, you can make it point to your own code. This is a Structured Exception Handling (SEH) exploit, and it allows you to completely bypass the canary check.

DEP and NX (what OpenBSD calls W^X) mark important structures in memory as non-executable, and force hardware-level exceptions if you try to execute those memory regions. This makes normal stack buffer…

1. "interesting definitions"...

Understood.

2. code size: I see that conceptually these 2 code samples work similarly, but one has 5x more LOC.

I think that's nit-picking a bit, especially since, as I said, there are some other convenience functions that could be used depending on the situation. But regardless, it's hardly onerous. We're talking about 7 lines of actual code vs. 2 lines. That's not even worth arguing about, especially as most applications do this once if they're permanently dropping privileges.

3. dropping and picking up isn't really dropping: If I drop privileges, but can pick them back up, then if I decide to misbehave, picking them back up is just something I do first. Dropping them with the possibility of picking them up is security theater, not actual security.

No, it's actually not security theatre at all. I think you misunderstand the threat model that's trying to be addressed. The kernel is enforcing the restrictions.

Note that I also specifically said Solaris allows both -- the developer can temporarily drop privileges or can permanently drop them or use a combination thereof. Each style of interface is appropriate for a different situation.

For example, consider a case where your program allows the execution of a user script to retrieve a password required to unlock an SSL Private Key file (Apache does this). For the duration of that operation, you can set your effective privileges to be very limited, and thus any programs you…

I think it's worth (re)reading this comment on the original Storage Pod from several years ago:

http://www.c0t0d0s0.org/archives/5899-Some-perspective-to-this-DIY-storage-server-mentioned-at-Storagemojo.html

I have essentially have all of the same questions for Storage Pod 3.0 -- and in particular, what does the software stack look like? (This config is absolutely begging for ZFS, but I have a haunting feeling that something janky is afoot upstack.) I would also be curious as to the specific nature of failures that have been seen with the deployed architecture. Have the concerns from three years ago proven to be alarmist or prescient?

That said: I think it's very valuable to get configs like this out there for public discussion -- and I think it might be inspiring us (Joyent) to similarly publicly discuss our own high density storage config...

If you are on Solaris (10 or higher works from experience) you can grant a single user the ability to bind to the lower ports:

usermod -K defaultpriv=basic,net_privaddr ${user}

You can off course also assign the privileges to a role, and then assign the user that role so as required they can su to the role and use the privileges.

Here is a pretty neat description of what is possible and why it is pretty awesome: http://www.c0t0d0s0.org/archives/4075-Less-known-Solaris-features-RBAC-and-Privileges-Part-3-Privileges.html

---

On FreeBSD if you have the MAC framework enabled, you can use the portacl module to give new privileges:

sysctl security.mac.portacl.rules=uid:$user_id:tcp:80

See http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/mac-portacl.html for more information.

I genuinely can't think of anything else I'd rather use less than this.

I think MAC (Mandatory Access Control) applied to a desktop environment, picking a better language than C and actually thinking about stuff is more than sufficient to get around the existing problems...

Virtualization is just another pile of complexity and performance problems to deal with. It's not a magic bullet. Consider the following as well:

http://www.c0t0d0s0.org/archives/3651-Theo-de-Raadt-about-virtualisation.html

I really don't want this solution.

Basically, it's a more-current version of the Linux kernel added to their distro (which is a clone of RHEL5).

Surprise surprise... the newer kernel has more performance optimizations and is somewhat faster/featureful.

There are a few new features - see here for more on one of the data integrity ones:

http://www.c0t0d0s0.org/archives/6919-About-this-data-integrity-thing-in-Oracle-ULK.html#extended