Beta

Slashdot: News for Nerds

×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Openwall Linux 3.0 — No SUIDs, Anti-Log-Spoofing

Soulskill posted more than 3 years ago | from the wouldn't-an-open-wall-be-a-gate dept.

Security 122

solardiz writes "Openwall GNU/*/Linux (or Owl for short) version 3.0 is out, marking 10 years of work on the project. Owl is a small, security-enhanced Linux distro for servers, appliances, and virtual appliances. Two curious properties of Owl 3.0: no SUID programs in the default install (yet the system is usable, including password changing); and logging of who sends messages to syslog (thus, a user can't have a log message appear to come, say, from the kernel or sshd). No other distro has these. Other highlights of Owl 3.0: single live+install+source CD, i686 or x86_64, integrated OpenVZ (host and/or guest), 'make iso' & 'make vztemplate' in the included build environment, ext4 by default, xz in tar/rpm/less, 'anti-Debian' key blacklisting in OpenSSH. A full install is under 400 MB, and it can rebuild itself from source."

cancel ×

122 comments

Amazing Work (4, Interesting)

metrix007 (200091) | more than 3 years ago | (#34592368)

While OpenWall won't see much adoption on it's own I do hope a lot of the work gets ported to other distributions so it is in common use.

Not trolling, but Linux Security is somewhat atrocious these days with the whole security via obscurity approach, so I for one have a better state of mind when I know I can protect myself even in the result of a succusful exploit.

Not Trolling? (1, Troll)

mpapet (761907) | more than 3 years ago | (#34592720)

t Linux Security is somewhat atrocious these days with the whole security via obscurity approach

Your ideas are intriguing to me. I would like to subscribe to your newsletter.

Re:Not Trolling? (1)

metrix007 (200091) | more than 3 years ago | (#34592730)

It's not surprising I have been modded down already, but I am referring to the policy of the developers not to disclosure security bugs that can result in remote compromise, and not to treat them with any priority. A policy I find appalling.

Re:Not Trolling? (0, Flamebait)

Markos (71140) | more than 3 years ago | (#34593478)

You are getting modded down because you claim Linux practices security through obscurity.

By definition, it's impossible for open source software to practice security through obscurity.

Re:Not Trolling? (3, Informative)

MichaelSmith (789609) | more than 3 years ago | (#34593628)

By definition, it's impossible for open source software to practice security through obscurity.

When you have mass quantities of obscure code it is certainly possible to do that for a while.

Re:Not Trolling? (0)

Markos (71140) | more than 3 years ago | (#34594400)

The typical definition of "security through obscurity" refers to hiding bugs and vulnerabilities by keeping the design and implementation secret via closed source. Neither the design or implementation is secret in open source software, so by definition the OPS statement is incorrect.

Re:Not Trolling? (2)

MichaelSmith (789609) | more than 3 years ago | (#34595836)

The typical definition of "security through obscurity" refers to hiding bugs and vulnerabilities by keeping the design and implementation secret via closed source.

No it means placing a reliance on something which is hard to find. If I hide my house key under a pot plant in my front yard I am relying on the obscure location of the key. The garden is open source. Anybody can search it.

Re:Not Trolling? (1)

Markos (71140) | more than 3 years ago | (#34598096)

http://en.wikipedia.org/wiki/Security_through_obscurity [wikipedia.org] "Security through (or by) obscurity is a pejorative referring to a principle in security engineering, which attempts to use secrecy (of design, implementation, etc.) to provide security."

Re:Not Trolling? (-1)

Anonymous Coward | more than 3 years ago | (#34594520)

This person is either a cohort, or the same person as Metrix007 using a different account. You can also safely ignore him. ( I am posting as AC because Metrix007 consistently stalks people and uses shill accounts to mod them down after he gets in an argument and loses miserably.)

Re:Not Trolling? (0)

Anonymous Coward | more than 3 years ago | (#34595016)

APK, take your paranoid fantasies somewhere else and stop following me. CAPTCHA: despair...hehehe

Re:Not Trolling? (0)

Anonymous Coward | more than 3 years ago | (#34595738)

Looking at the moderation in this thread, I'm inclined to agree.

Re:Not Trolling? (2, Insightful)

metrix007 (200091) | more than 3 years ago | (#34593680)

I am getting modded down because zealots have modpoints.

Most people who use Linux don't review the code nor should they be expected to. We should expect the developers to disclose security problems in a responsible way. They don't, they obscure them.

So yes, the developers do practice security via obscurity. DO I really need to go and link the interview on kerneltrap where they say and defend that practice?

Re:Not Trolling? (1, Insightful)

Markos (71140) | more than 3 years ago | (#34594310)

http://en.wikipedia.org/wiki/Security_through_obscurity [wikipedia.org] "Software which is deliberately released as open source cannot be said to be relying on security through obscurity (the design being publicly available), but it can nevertheless also experience security debacles (e.g., the Morris worm of 1988 spread through some obscure—though widely visible to those who looked—vulnerabilities)."

Re:Not Trolling? (2)

AaronLS (1804210) | more than 3 years ago | (#34594648)

So if I release a program that encrypts data by XOR'ing all bits, it is not security through obscurity simply if I release it as open source? That is the classic example of security through obscurity, and making it open source doesn't change that. The open source aspect of it only means that people will potentially discover this problem.

If you've ever released something on source forge you should compare your stats regarding people accessing the source code versus downloads. You will find the source code is next to never downloaded if you are providing binaries.

Re:Not Trolling? (1)

Markos (71140) | more than 3 years ago | (#34594702)

That is an example of code obfuscation not security through obscurity.

Re:Not Trolling? (1)

fbjon (692006) | more than 3 years ago | (#34594900)

That's a different area of security: encryption or security offered by a piece of software, as opposed to the security of the software itself, though they may be related.

Re:Not Trolling? (0)

Anonymous Coward | more than 3 years ago | (#34594928)

Well, sure, Wikipedia is one definition. On the other hand, if developers know about security vulnerabilities and do not disclose them or or treat them as a priority, then that is also security via obscurity.

What with them relying on it not being exploited due ti it being obscure due them not disclosing it and all.

Re:Not Trolling? (1)

santax (1541065) | more than 3 years ago | (#34593596)

Don't agree with you being nodded troll, but also don't agree with what you say. There is a very good mailing-list, called full-disclosure. The devs have no choice. The bugs and exploits will be on that list. All of them.

Re:Not Trolling? (1)

metrix007 (200091) | more than 3 years ago | (#34593698)

The point is that Linux devs often only make a patch after being forced to. At the moment there are many problems which they just ignore as they don't consider the problems interesting or as important as getting the scheduler .0000001% faster.

Re:Not Trolling? (1)

santax (1541065) | more than 3 years ago | (#34593848)

Hmmmz only problem that comes to mind is proftpd, but the dev patched that I think. Just the distro's not. Can you name some more? Cause I believe the devs normally (95%+) fix a security problem asap.

Re:Not Trolling? (1)

metrix007 (200091) | more than 3 years ago | (#34594020)

Well I am referring to the Linux kernel, not anything else. Look at that recent root hole this year...it was known about for a few weeks and only fixed when pressured to via full disclosure.

Re:Not Trolling? (1)

kermyt (99494) | more than 3 years ago | (#34594246)

normally when people are serious about not being called a troll they will include citations to back up what they are saying. Thus far you are totally trolling. Citations please?

Re:Not Trolling? (1)

metrix007 (200091) | more than 3 years ago | (#34594792)

Wow, google is hard. Let me help you with that.

Here [kerneltrap.org] and Here. [slashdot.org]

You can see here [mitre.org] that it was assigned more than 2 weeks before it was disclosed and started to be patched.

Re:Not Trolling? (-1)

Anonymous Coward | more than 3 years ago | (#34594934)

Making blanket statements based on a single incident is still trolling. Sorry.

Re:Not Trolling? (1)

metrix007 (200091) | more than 3 years ago | (#34596626)

You asked for proof, you can't expect an entire case history. Do your own damn research, zealot. If nothing else there is definite proof that the developers have at least on one occasion practices security via obscurity.

Proof of metrix007 trolling & fuck up (0)

Anonymous Coward | more than 3 years ago | (#34599082)

metrix007 is pissed about this http://yro.slashdot.org/comments.pl?sid=1888084&cid=34462614 [slashdot.org] where he blundered on hosts files against a person he was trolling there. metrix007 got played. He played himself, and right on his first attempted trolling reply. Hilarious.

metrix007 got played? metrix007 played himself. (0)

Anonymous Coward | more than 3 years ago | (#34599092)

metrix007 is pissed about this http://yro.slashdot.org/comments.pl?sid=1888084&cid=34462614 [slashdot.org] where he blundered on hosts files against a person he was trolling there. metrix007 got played. He played himself, and right on his first attempted trolling reply and he ran like a scared beyotch after that. Hilarious. Then, metrix007, who was still stinging from his bad fuckup due to his skimming and trolling, attempted to troll that same person again and failed once more http://tech.slashdot.org/comments.pl?sid=1901826&cid=34528502 [slashdot.org] because the +5 moderation still stands strong versus metrix007's trolling and blatant technical screw ups.

metrix got played. metrix007 played himself! (0)

Anonymous Coward | more than 3 years ago | (#34599098)

metrix007 is pissed about this http://yro.slashdot.org/comments.pl?sid=1888084&cid=34462614 [slashdot.org] where he blundered on hosts files against a person he was trolling there. metrix007 got played. He played himself, and right on his first attempted trolling reply and he ran like a scared beyotch after that. Hilarious. Then, metrix007, who was still stinging from his bad fuckup due to his skimming and trolling, attempted to troll that same person again and failed once more http://tech.slashdot.org/comments.pl?sid=1901826&cid=34528502 [slashdot.org] because the +5 moderation still stands strong versus metrix007's trolling & blatant technical screw ups.

Not smart enuogh to Troll? (0)

Anonymous Coward | more than 3 years ago | (#34594276)

It has been explained to this moron ad naseum that the priority of all bugs in the Linux kernel is 100%, and that they are not treated any different because each in every bug that is identified gets fixed as soon as humanly possible. There is a lot more to the story than that as well, and he continues to either pretend to be completely stupid and unable to understand how the Linux development process assures security, or is actually that stupid. He is a known troll. Just ignore him.

Re:Not smart enuogh to Troll? (0)

Anonymous Coward | more than 3 years ago | (#34595126)

Good old Zero_Kelvin. Still failing to understand basic concepts and falling prone to zealotry and confirmation bias. A shame.

What's worse is thinking that a post from APK who actually is a well known troll calling me a troll is proof that metrix007 is a well known troll.

How sad.

Re:Not smart enuogh to Troll? (0)

Anonymous Coward | more than 3 years ago | (#34596344)

a post from APK

That post didn't have near enough ALL CAPS,

longwinded quotes of dubious relationship to the subject at hand

and randomly bolded words to be an APK post.

Re:Not smart enuogh to Troll? (1)

metrix007 (200091) | more than 3 years ago | (#34596634)

Well, APK has been following me around so I'm pretty sure it's him. What I think is far more odd than the caps and bolding is the random putting in quotes of normal everyday phrases. I just imagine him making quoting gestures in real life rather compulsively.

metrix007 the troll got PLAYED. (-1)

Anonymous Coward | more than 3 years ago | (#34599106)

metrix007 is pissed about this http://yro.slashdot.org/comments.pl?sid=1888084&cid=34462614 [slashdot.org] where he blundered on hosts files against a person he was trolling there. metrix007 got played. He played himself, and right on his first attempted trolling reply and he ran like a scared beyotch after that. Hilarious. Then, metrix007, who was still stinging from his bad fuck up due to his skimming and trolling, attempted to troll that same person again and failed once more http://tech.slashdot.org/comments.pl?sid=1901826&cid=34528502 [slashdot.org] because the +5 moderation still stands strong versus metrix007's trolling and blatant technical screw ups.

Re:Amazing Work (1)

ehrichweiss (706417) | more than 3 years ago | (#34595064)

commenting to kill an accidentally bad mod...

Re:Amazing Work (1)

Eil (82413) | more than 3 years ago | (#34595854)

Not trolling, but Linux Security is somewhat atrocious these days with the whole security via obscurity approach

In order to qualify as "not trolling," you have to explain which parts of Linux rely on security through obscurity. The source code to Linux is completely out in the open and available to anyone who wants to study how it works. What do you think is hidden?

Re:Amazing Work (1)

metrix007 (200091) | more than 3 years ago | (#34596642)

I think the security vulnerabilities are hidden in that the developers choose not to disclose them to people who don't bother to review the entire source tree. It's the perfect example of security via obscurity.

Re:Amazing Work (1)

solardiz (817136) | more than 3 years ago | (#34597986)

> I do hope a lot of the work gets ported to other distributions so it is in common use.

Not only to other distributions, but also to upstreams (for software that we package). Both of these things have been happening throughout the 10 years (individual pieces and concepts got into "base systems" of ALT Linux, Mandriva, FreeBSD, DragonFly BSD, OpenBSD; other Openwall software is also packaged for all major Linux distros and *BSDs; many of our patches got into upstream repositories/versions of software that we package), but we still do have more stuff to "export" - and we're trying to.

metrix007 you're always trolling (and failing) (-1)

Anonymous Coward | more than 3 years ago | (#34599118)

metrix007 is pissed about this http://yro.slashdot.org/comments.pl?sid=1888084&cid=34462614 [slashdot.org] where he blundered on hosts files against a person he was trolling there. metrix007 got played. He played himself, and right on his first attempted trolling reply and he ran like a scared beyotch after that. Hilarious. Then, metrix007, who was still stinging from his bad fuckup due to his skimming and trolling, attempted to troll that same person again and failed once more http://tech.slashdot.org/comments.pl?sid=1901826&cid=34528502 [slashdot.org] because the +5 moderation still stands strong versus metrix007's trolling and blatant technical screw ups.

OMG (-1)

Anonymous Coward | more than 3 years ago | (#34592372)

FIRST SPOOF!

Awesome.. No need for Fortress Linux then? (2)

petril (109301) | more than 3 years ago | (#34592438)

This is pretty interesting, I just wonder what happens to Fortress Linux [fortresslinux.org] ?

Rebuild itself? (2)

Jeremiah Cornelius (137) | more than 3 years ago | (#34592446)

Can it do so with cross-compilation? I want this as an ARM distro...

Re:Rebuild itself? (3, Informative)

zn0k (1082797) | more than 3 years ago | (#34593006)

http://www.openwall.com/Owl/ARCHITECTURES.shtml [openwall.com]
> Cross-builds are not supported: it is not possible to build packages for an architecture different than that of the build host, nor for a flavor of the architecture newer than that implemented in the build host's CPU.

No, it can't do cross-compiling. And ARM is not supported.

Re:Rebuild itself? (1)

Jeremiah Cornelius (137) | more than 3 years ago | (#34593840)

Bummer. Zeroshell can be made to fit - but track all those separate sources? No way.

I guess it's packetprotector, on top of OpenWRT.

VMWare support? RAM requirements? (1)

billstewart (78916) | more than 3 years ago | (#34593146)

I'm interested in this for a VMware guest OS, as a possible alternative to m0n0wall. Have the authors thought about that kind of implementation? How much RAM does it need to run adequately?

Re:VMWare support? RAM requirements? (3, Informative)

JSG (82708) | more than 3 years ago | (#34593884)

There's always pfSense as an alternative to m0n0wall. I run many of those under VMWare.

I chose it for its easy multi external link capabilities, after I gave up on Linux for this and was pleasantly surprised by its ease of use, stability and huge range of features.

It is nearly bullet proof as I discovered when one of a customer's VMFS died. All the other VMs fell over immediately but the pfSense router carried on running without its "hard disc" for two days before I replaced it. Internet access downtime was 2 seconds as I cut it over. Admittedly the web interface vanished but the routing, VPNs, firewall etc carried on running.

As to OWL, its a Linux distro so it will have no problems with being a VM - that's the whole point of virtualization. You might have to select "Linux other (64 bit)" but my many Gentoo's run happily like that

Why on earth should the devs even think about VMWare, HyperV, KVM or whatever - that's your job! Apart from considering making the guest tools pre-packaged what should they be doing? I doubt they care whether you spec your boxen from Dell. HP, IBM or PC World so why should they care whether it is physical or VM?

As to asking about RAM requirements - I'd suggest (without even having looked at it) >=256Mb depending what you do with it. I've no doubt that fact is covered on their web site. If you are using ESXi and not just playing on your home PC then the answer would probably be "who cares, RAM is cheap as chips"

Go on - try it, I might even do the same.

Cheers
Jon

PS You have a 5 digit /.ID. Have you been moonlighting on other OSs for the last 10 years, asking such questions 8)

Re:VMWare support? RAM requirements? (1)

Jeremiah Cornelius (137) | more than 3 years ago | (#34594298)

Agreed. Perfect appliance baseline. Most appliances don't want package mangement outside the scope of their platform workload, anyway.

Re:VMWare support? RAM requirements? (2)

solardiz (817136) | more than 3 years ago | (#34598562)

I'm interested in this for a VMware guest OS, as a possible alternative to m0n0wall. Have the authors thought about that kind of implementation

Yes, Owl 3.0 works in VMware out of the box. We mostly run it in QEMU and VirtualBox for our VM-based testing, though.

BTW, you might find it curious that when you run Owl in a VM like this, you can further create OpenVZ containers with multiple instances of Owl and with other Linux distros inside that single running copy of Owl. Such container-based virtualization has no further performance overhead. :-)

How much RAM does it need to run adequately?

128 MB is plenty, probably a lot less will do. I have my QEMU set to its default of 128 MB when I do install-tests with new Owl ISOs. Also, my Owl-based router and small fileserver at home has 128 MB RAM (runs the default-enabled set of Owl services plus ntpd, named, pppd/pppoe, openvpn, squid, NFS, and a sometimes a few lftp's and ctorrent's under screen).

On the other hand, of course you may need a lot more RAM for your specific uses of Owl - e.g., to run many OpenVZ containers, to do web hosting, etc. We currently administer several 32 GB RAM machines running Owl and one 64 GB RAM machine, as well as a countless number of 4-16 GB machines - so we know Owl has no problem with these larger RAM sizes as well (and with the many OpenVZ containers running various Linux distros actually making use of this RAM).

Re:Rebuild itself? (0)

Anonymous Coward | more than 3 years ago | (#34596370)

Yes, Fortress Linux will include pre-compiled packages and source packages. Lets say Gentoo/LFS and Slackware/Ubuntu style.
I had Fortress Linux running on a Zyxel router (ARM9) before I trashed the bootloader of that router... bricked :) x86 in the first Alpha only.

Openwall... secure? webbased interfaces can be very vulnerable. That is why I installed FL on my Zyxel router.. DDos/ passwd exploitable.

I don't think Openwall supports grsec, containers, Cuda etc. ? I bet they still use deprecated software like Snort.

Palatinux
 

Re:Rebuild itself? (1)

solardiz (817136) | more than 3 years ago | (#34598490)

Openwall... secure? webbased interfaces can be very vulnerable.

There's no web-based interface in Owl.

I don't think Openwall supports grsec, containers, Cuda etc. ? I bet they still use deprecated software like Snort.

Are you just trolling? I'll provide a serious response nevertheless: we don't include the grsecurity patch, but our userland will run just fine with a grsecurity-patched kernel - this is up to our users to choose if they like. We do support containers out of the box, with OpenVZ. Owl can act both as an OpenVZ host (it includes the kernel and vz* tools) and guest (we provide pre-created OpenVZ container templates, and there's "make vztemplate" to build your own ones if you like). CUDA has nothing to do with a server/appliance Linux distro at this time (although I can think of some obscure uses). Since when is Snort deprecated? Anyway, we don't include it, but it can be easily installed on top of Owl.

Re:Rebuild itself? (1)

gm.outside (1961160) | more than 3 years ago | (#34597196)

No, officially we don't support ARM, but I have plans to make an ARM build of a stripped down Owl since the number of ARM-based devices is rapidly growing at my home. :) A DSL modem, a NAS box, and a couple of netbooks - all are ARM based. This gives me a lot of temptation to build Owl for ARM. :)

Anti-debian key? (3, Interesting)

gandhi_2 (1108023) | more than 3 years ago | (#34592506)

Can someone explain (for real) the point of the 'anti-Debian' key blacklist?

Is it because of the Debian-specific vulnerability in OpenSSH? I thought that was a couple years ago.

Re:Anti-debian key? (5, Informative)

wowbagger (69688) | more than 3 years ago | (#34592606)

The exploit was years ago, but you never know when somebody generated a key under the broken system, and hasn't regenerated their key due to (missing the memo|laziness|stupidity) and is still using a weak key.

So, many distros block the bad keys to force people to clean up.

Re:Anti-debian key? (5, Informative)

characterZer0 (138196) | more than 3 years ago | (#34593120)

Debian itself blocks the bad keys.

Re:Anti-debian key? (5, Informative)

Khopesh (112447) | more than 3 years ago | (#34592642)

Can someone explain (for real) the point of the 'anti-Debian' key blacklist?

Is it because of the Debian-specific vulnerability in OpenSSH? I thought that was a couple years ago.

Yes. There are still lots of keys out there that were generated with this bug, so it is still worthwhile to test for that. When it comes to uber-secure projects like OWL and OpenBSD, this will likely never change; it's a trivial check for a nontrivial gain.

Re:Anti-debian key? (1)

Anonymous Coward | more than 3 years ago | (#34595748)

> uber-secure projects like OWL and OpenBSD

Really, did you have to throw OpenBSD in there *right now?*

Re:Anti-debian key? (0)

Anonymous Coward | more than 3 years ago | (#34596078)

Really, did you have to throw OpenBSD in there *right now?*

How about now? Too soon?

(seemed like a valid point to me...)

Ah Sweet Nostalgia (4, Insightful)

ADRA (37398) | more than 3 years ago | (#34592512)

While I'm not terribly interested in the distribution itself, its great to see a classic Slashdot story about some major or point release of a semi-well known OSS product.

What is it good for? (1)

mangu (126918) | more than 3 years ago | (#34592588)

The exploits named in the summary are mostly for locally connected users, which means academic environments. I mean, how would you send a message to syslog over the web?

The kind of secure system one needs today is mostly about the web server, if it doesn't come through port 80 it never reaches the server because the router blocks it.

Re:What is it good for? (0)

Anonymous Coward | more than 3 years ago | (#34592882)

how would you send a message to syslog over the web?

If you mean over the network when you say "over the web", perhaps by faking remote logging?

http://www.rsyslog.com/sending-messages-to-a-remote-syslog-server/ [rsyslog.com]

I don't think this will be much help in such a case though.

But faking logs is probably sometimes useful to do once you've gained access to a system via "the web", though.

Re:What is it good for? (1)

mangu (126918) | more than 3 years ago | (#34593026)

If you mean over the network when you say "over the web"

When I say "over the web" I mean TCP port 80. Everything else stops at the router.

Re:What is it good for? (0)

Anonymous Coward | more than 3 years ago | (#34593142)

I'm curious as to how you implement SNMP and POP3 over port 80.

Re:What is it good for? (0)

Anonymous Coward | more than 3 years ago | (#34593210)

mangu is a fucking idiot and obviously there's a shitload of traffic going over the internet on ports other than 80, but if you're sending your SNMP traffic over the internet you're a bigger idiot.

Re:What is it good for? (0)

Anonymous Coward | more than 3 years ago | (#34593254)

Not an idiot, just acronym challenged. That should have been SMTP, of course.

Re:What is it good for? (1, Interesting)

mangu (126918) | more than 3 years ago | (#34593440)

I'm curious as to how you implement SNMP and POP3 over port 80.

Sorry, I didn't know that the World Wide Web [wikipedia.org] had been expanded to include network management [wikipedia.org] or email. I was under the impression that it was only about hypertext [wikipedia.org] .

I didn't say "over the network", did I? POP3 and SNMP are typically services that you find in an academic network, but nowadays everything else that is provided by a commercial service comes through port 80. My ISP does have a POP3 option, but why would I have an email address that's attached to an ISP when I can use gmail?

Re:What is it good for? (1)

Lennie (16154) | more than 3 years ago | (#34593712)

Because you have your own domain. :-)

Re:What is it good for? (1)

LordLimecat (1103839) | more than 3 years ago | (#34594798)

Because Gmail provides POP3 for people who want to use any one of the zillions of email clients out there? Because Gmail relies on SMTP (port 25) for sending and receiving email? Because SNMP is widely used internally at many businesses for monitoring and administration of network appliances?

Not to mention, I cant imagine why you think schools use POP3 more than anyone else; Northern VA community college outsources gmail, Georgetown U uses a web based client (which actually also has an IMAP client), and I think GMU uses gmail. 3 fairly large schools around here which dont really use POP3 that much, if at all.

Re:What is it good for? (1)

gm.outside (1961160) | more than 3 years ago | (#34597232)

Well, a poorly written script (and there are many of these nowadays) on a web server may allow an execution of an arbitrary process on the server -- so our hardening measures will try protect the system from the inside. Indeed, this is a quick response on your question, feel free to ask if you want me to elaborate further on this topic.

Re:What is it good for? (1)

solardiz (817136) | more than 3 years ago | (#34598456)

The exploits named in the summary are mostly for locally connected users, which means academic environments.

Yes, local users and pseudo-users. No, this is not limited to academic environments. Think shared web hosting - hundreds or thousands of local users on a system. We're actually setting up Owl-based shared web hosting systems for our clients. Besides the different user accounts belonging to different shared hosting customers, privilege separation between the accounts is also needed because one of the websites may get compromised (via a web app vulnerability) and we would not want such a compromise to easily propagate onto all other websites hosted on the same system (not even if they're of the same customer).

Additionally, even on a dedicated server for a single website (or, say, on a mail server) there are pseudo-users. Even the sshd service from OpenSSH uses a pseudo-user for its built-in privilege separation. This is needed to mitigate the impact of vulnerabilities in certain parts of code in those services (and in libraries that they use). You don't want any vulnerability anywhere in sshd or in parts of libc/libcrypto/libz that it uses (and in a lot of other libraries on riskier Linux distros such as RHEL/CentOS/Fedora - just see "ldd /usr/sbin/sshd" on those and be very scared) to result in a full-blown root compromise. The extra barrier between the less-privileged sub-process (doing lots of things) and the parent root-privileged process (doing fewer things) is of some help. Ditto for other services that implement privilege separation - and this is the kind of service implementations that we include in Owl (OpenSSH, vsftpd, OpenNTPD, Postfix all have privsep implemented upstream; telnetd was missing privsep, but we introduced privsep into it).

/bin/su isn't SUID?! (2)

Khopesh (112447) | more than 3 years ago | (#34592600)

I'm not sure I believe that. The only way I can think of permitting things like su and passwd (among many others) is by running some sort of permissions escalation daemon ("owl-control" perhaps?) as root that essentially does the same thing. This moves the vulnerability from the binary to the permissions daemon.

There is almost no documentation on owl-control; the best I could find was a FreeBSD port [uni-marburg.de] and the (encoded) man page [openwall.com] as plucked from CVS HEAD.

If this has been independently audited and continues to appear to be a Good Idea then perhaps it would be of interest to one of the larger distributions?

Re:/bin/su isn't SUID?! (3, Informative)

verbatim_verbose (411803) | more than 3 years ago | (#34592840)

See Fedora's page [fedoraproject.org] for the same feature.

In short, there is a system now which gives programs certain capabilities based on tags set in the file system. With this, running as root is not needed for most things.

Re:/bin/su isn't SUID?! (1)

gm.outside (1961160) | more than 3 years ago | (#34597356)

No, Fedora are using a different approach. We do not replace SUID/SGID with capabilities, instead we carefully design the system to take advantage of the standard Un*x OS level permissions. JFYI, all this buzz with replacing SUID/SGID binaries emerged from the recently discovered vulnerability (BTW, Owl was among few distributions which wasn't affected by that vulnerability at all), but unfortunately people are often getting things wrong, when it comes to security. Please review the following message that describes some pitfalls along Fedora or Ubuntu's ways: http://www.openwall.com/lists/oss-security/2010/11/08/3 [openwall.com] .

Re:/bin/su isn't SUID?! (1)

gm.outside (1961160) | more than 3 years ago | (#34597380)

Oh, fandingo has already quoted the entire message I provided link for in his/her comment "Dropping SUID doesn't improve security", however I don't agree with the comment title since proper dropping of SUID _DOES_ improve security, and Owl is one of such examples.

Re:/bin/su isn't SUID?! (1)

bluefoxlucid (723572) | more than 3 years ago | (#34592886)

A curious detail is that there are no SUID programs in a default install of Owl 3.0. Instead, there are some SGIDs, where their group level access, if compromised via a vulnerability, can't be expanded into root access without finding and exploiting another vulnerability in another part of the system - e.g., a vulnerability in crontab(1) or at(1) can't result in a root compromise without a vulnerability in crond(8) or in a critical system component relied upon by crond(8).

From some googling and the announcement.

Basically if you exploit something with 'shadow' (i.e. passwd) you add a root user account to /etc/passwd and su to it. if you exploit crontab or at, you add a crontab that adds a root level account or runs a command as root or creates a SUID program. It requires some hacker creativity, but doesn't make anything secure.

Re:/bin/su isn't SUID?! (1)

Bert64 (520050) | more than 3 years ago | (#34593102)

Depends on the program, exploiting a setuid ping would give you root, exploiting a ping with the capability to open raw sockets would give you the ability to open raw sockets, still bad but nowhere near as critical.
It also as you pointed out makes it harder for exploit writers, most "hackers" are script kiddies who will use exploits written by other people, which may not target things like this (and certainly don't yet).

Re:/bin/su isn't SUID?! (1)

solardiz (817136) | more than 3 years ago | (#34598346)

Speaking of ping in particular, I have to admit that in Owl 3.0 it is simply restricted to invocation by root by default (mode 700) - not great, but usually acceptable. It can be re-enabled with "control ping public", and this setting will persist over upgrades, but it re-introduces the risk. We're working towards a better solution - specifically, we're testing a Linux kernel patch implementing non-raw ICMP sockets, which we intend to submit to LKML soon. (It already works for us, including via our patched ping, but this stuff was too cutting-edge to include it in the release.)

traceroute just works on Owl out of the box, though - we're using an implementation that makes use of Linux-specific kernel features (upstream, no patches) such that it does not need any special privileges to run (it is installed mode 755 and it works for all users). (This is similar to what we're trying to implement for ping, but it's already a reality.)

Re:/bin/su isn't SUID?! (1)

gm.outside (1961160) | more than 3 years ago | (#34597490)

Basically if you exploit something with 'shadow' (i.e. passwd) you add a root user account to /etc/passwd and su to it.

This is not true. You can't do anything like this even if you acquire the shadow membership:

server!galaxy:~$ ls -ld /etc/passwd /etc/tcb
-rw-r--r-- 1 root root 3956 2010-06-03 21:08 /etc/passwd
drwx--x--- 99 root shadow 4096 2010-06-03 21:08 /etc/tcb
server!galaxy:~$

and the structure under /etc/tcb/ is also not writable to shadow:

server!root:~# ls -ld /etc/tcb /etc/tcb/galaxy
drwx--x--- 99 root shadow 4096 2010-06-03 21:08 /etc/tcb
drwx--s--- 2 galaxy auth 4096 2009-10-24 04:44 /etc/tcb/galaxy
server!root:~#

Re: crontab -- good luck with hijacking crontab on Owl :). The code was carefully audited for security issues and was hardened against possible abuses.

Re:/bin/su isn't SUID?! (1)

solardiz (817136) | more than 3 years ago | (#34598360)

From some googling and the announcement.

Basically if you exploit something with 'shadow' (i.e. passwd) you add a root user account to /etc/passwd and su to it. if you exploit crontab or at, you add a crontab that adds a root level account or runs a command as root or creates a SUID program. It requires some hacker creativity, but doesn't make anything secure.

That's poor analysis on your part, so your conclusion is completely wrong. Please refer to our presentation slides for an explanation of how things actually work and why the attacks you describe would not work:

http://www.openwall.com/presentations/Owl/ [openwall.com]

BTW, the announcement specifically mentioned that "a vulnerability in crontab(1) or at(1) can't result in a root compromise without a vulnerability in crond(8) or in a critical system component relied upon by crond(8)." Did you not read that? Or do you disagree, thereby stating that we're inexperienced in the stuff we've been doing for 10 years?

Since a lot of people are confused just like you are, I'd be happy for any suggestions on how we could explain what we do and what we have achieved better. I did include that quote in the announcement specifically because I knew of common misconceptions about our work, but apparently that was not enough? Thanks!

Re:/bin/su isn't SUID?! (0)

Anonymous Coward | more than 3 years ago | (#34592898)

At least theoretically some type of access list "Program X is authorized to do Y" is more secure than "Program X needs root access". But I agree that more information about owl-control would be great. Slashdot is supposed to be informative rather than just "Cool Linux product available now!!!!"

Re:/bin/su isn't SUID?! (2)

Khopesh (112447) | more than 3 years ago | (#34593092)

At least theoretically some type of access list "Program X is authorized to do Y" is more secure than "Program X needs root access".

I chose /bin/su because the "Y" that it needs to do is root access.

Re:/bin/su isn't SUID?! (0)

Anonymous Coward | more than 3 years ago | (#34594972)

The new system allows /bin/su to have permission to write to /etc/passwd, but not to do other root things like read/write to /root or mount filesystems not enumerated in /etc/fstab. It is "granular root".

Re:/bin/su isn't SUID?! (1)

solardiz (817136) | more than 3 years ago | (#34598312)

The new system allows /bin/su to have permission to write to /etc/passwd, but not to do other root things like read/write to /root or mount filesystems not enumerated in /etc/fstab. It is "granular root".

You're talking of Fedora's approach with fscaps (and there are errors in your description). We don't do that. We're smarter than that! So your comment does not apply to Owl, at all. I've explained what we actually do in further comments. It is also shown in our presentation slides:

http://www.openwall.com/presentations/Owl/ [openwall.com]

Specifically:

http://www.openwall.com/presentations/Owl/mgp00013.html [openwall.com]
http://www.openwall.com/presentations/Owl/mgp00020.html [openwall.com]

(and further slides, just click "next").

Re:/bin/su isn't SUID?! (2)

Bert64 (520050) | more than 3 years ago | (#34593060)

Well, setuid binaries were required to exploit the ptrace kernel vulnerability from a few years back, as well as the more recent vulnerability in glibc... An already running daemon which is running as root would not be vulnerable to either of these exploits.

On the other hand, i believe they use capabilities - that is rather than granting full root privileges ala setuid, you grant only the permissions a program needs... For instance listening daemons may only need root privileges to bind to ports below 1024, ping/traceroute only need to be able to open a raw socket etc.

Re:/bin/su isn't SUID?! (1)

solardiz (817136) | more than 3 years ago | (#34598268)

On the other hand, i believe they use capabilities ...

No, we don't! We're smarter than that. I've explained what we do in further comments (in the thread about my criticism of Fedora's approach).

Re:/bin/su isn't SUID?! (1)

gm.outside (1961160) | more than 3 years ago | (#34597274)

Yes, our distro doesn't encourage users to use su or sudo. The reason is that escalating privileges from a less privileged account to a more privileged account is bad from security standpoint. I found the following message in our mailing list. In this message Solar Designer explains the issue with su/sudo: http://www.openwall.com/lists/owl-users/2004/10/20/6 [openwall.com] An excerpt from the above message: "Presently, the only safe use for su is to switch from a more privileged account to a less privileged one (whenever this distinction can be made) in a non-interactive script (without a tty). As soon as a tty is used, there is a security problem. As soon as you su to a more privileged account, there is another security problem." I hope you'd find this useful.

Re:/bin/su isn't SUID?! (1)

solardiz (817136) | more than 3 years ago | (#34598296)

Yes, our distro doesn't encourage users to use su or sudo. The reason is that escalating privileges from a less privileged account to a more privileged account is bad from security standpoint.

Exactly. And our solution to the "accountability" problem when there's more than one sysadmin is multiple root accounts - we typically prefix their usernames with "r_" for clarity, and we keep the main "root" account locked. We even have our own msulogin program, replacement for sulogin, to allow for single user mode console logins under any one of multiple root accounts that might exist on the system. The rest of Linux tools happened to just work with multiple root accounts fine, with no changes needed on our part.

That said, if anyone truly wants to use the traditional absurd approach of su'ing to root, they can re-enable su with "control su wheelonly" (there are other possible settings as well). Of course, this makes /bin/su SUID root... but you asked for it. This setting will persist over Owl upgrades. See "man control", "control" (just run it with no options for a list of facilities and their possible settings).

Re:/bin/su isn't SUID?! (1)

Compaqt (1758360) | more than 3 years ago | (#34598416)

If you can't su or sudo, how you get anything done?

Re:/bin/su isn't SUID?! (1)

gm.outside (1961160) | more than 3 years ago | (#34598680)

If you can't su or sudo, how you get anything done?

This depends on the task. If you are a local user and need root powers - switch your console to a fresh one and login as root. If you were talking about getting root powers on a remote host, the best practice is to ssh as root directly (given that you are behind a trusted terminal).

Re:/bin/su isn't SUID?! (1)

solardiz (817136) | more than 3 years ago | (#34598692)

If you can't su or sudo, how you get anything done?

We normally login directly as a root user for sysadmin tasks (e.g., r_john for a sysadmin named John) and also directly as a non-root user (e.g., john) for other tasks. This applies to both console and remote logins (ssh). This is the approach we've been using for years, and it works well for us.

As I have mentioned, those who prefer the traditional su approach, despite of its added risks (including compromise propagation from a sysadmin's non-root account to root), may "control su wheelonly".

Re:/bin/su isn't SUID?! (1)

solardiz (817136) | more than 3 years ago | (#34598402)

some sort of permissions escalation daemon ("owl-control" perhaps?)

owl-control is merely a tool to ease system administration - change settings and have your changes persist over system upgrades. It is one of the nice security-related features of Owl, but it is NOT key to running a reasonable Owl system without SUIDs (this is achieved by other means - SGIDs and changes to various system components). owl-control is not what you thought it was (not a "permissions escalation daemon", but merely a set of scripts).

I do agree with you that we need to present our documentation (such as man pages) in a form more accessible to someone who is not an Owl user yet. The only reason why we did not do that yet is lack of time (small development team working on a mostly non-commercial project, so we constantly have to choose which of the pending tasks we make progress on).

just the capability to grant any capability (0)

Anonymous Coward | more than 3 years ago | (#34598794)

No, it is not SUID. It just has the capability to grant any capability to the user. LOL.

Is this stuff important? (1)

Anonymous Coward | more than 3 years ago | (#34592656)

Two curious properties of Owl 3.0: no SUID programs in the default install (yet the system is usable, including password changing); and logging of who sends messages to syslog (thus, a user can't have a log message appear to come, say, from the kernel or sshd). No other distro has these.

Of all the Linux vulnerabilities in the past few years, how many would have been stopped by this?

These things sound nice, but I'm wondering if they are actually useful or if they are just security theater.

Re:Is this stuff important? (1)

solardiz (817136) | more than 3 years ago | (#34598248)

Of all the Linux vulnerabilities in the past few years, how many would have been stopped by this?

There were in fact cases where other Linux distros had to issue updates and advisories - e.g., for an issue in crontab (to use the same example that I used for some other comments here) - whereas on Owl not only the vulnerability did not exist in the first place, but also it would have been mitigated due to the greatly reduced privileges of the crontab program (to use the same example again). To give another example, the recent glibc vulnerability with LD_AUDIT and $ORIGIN (discovered by Tavis Ormandy) not only did not affect Owl for a couple of reasons (including due to a glibc hardening patch), but also would be mitigated by not having a single SUID program if the vulnerability did exist on Owl (it did exist on almost all other distros). As you can see from this, we often have multiple layers of security hardening that help (with this being one of the layers) whereas others sometimes happen to have none - and are vulnerable.

At this point, our weakest link is the Linux kernel - large and monolithic - so that's pretty much the only place where critical vulnerabilities that do affect us are still being found... There's little we can do about this (while staying Linux), but it may be a focus area for further security hardening now that we have an almost perfect userland. Also, Owl differs from other/major distros as it relates to exposing the Linux kernel to attack - we expose less of it - e.g., we exclude kernel module auto-loading, we have saner/safer permissions on device files, and we have no SUIDs by default (which mitigates some classes of potential vulnerabilities in the Linux kernel's program startup code - such vulnerabilities were found/fixed in the past).

That was regarding "no SUIDs". As to the detection of log record spoofing, it does not stop attacks, but it is a security feature. When you review logs, you typically want to have a way to know whether the records are genuine, at least under the assumption that the system has not been compromised yet. On traditional Unix/Linux/BSD/..., you had to assume that any (pseudo-)user could have trivially produced any of the log records, pretending to be any system service or even the kernel.

SHI3T (-1)

Anonymous Coward | more than 3 years ago | (#34592676)

Finally! (1)

mpapet (761907) | more than 3 years ago | (#34592680)

News that matters.

Next up, Microsoft/Symantec/Cisco security product and costs 10's of thousands more! Can't leave the point-and-click jui jitsu black belts out.

Dropping SUID doesn't improve security (5, Informative)

fandingo (1541045) | more than 3 years ago | (#34592874)

Here's one of the better criticisms of dropping SUID, and it's from an Openwall developer. These criticisms are echoed by almost everyone thinking about removing SUID.

There's a lot of talk lately regarding replacing the SUID bit on program
binaries in Linux distros with filesystem capabilities. Specifically,
Fedora and Ubuntu are heading in that direction.

Fedora:
http://fedoraproject.org/wiki/Features/RemoveSETUID [fedoraproject.org]
https://bugzilla.redhat.com/show_bug.cgi?id=646440 [redhat.com]

Ubuntu:
http://www.outflux.net/blog/archives/2010/02/09/easy-example-of-fscaps/ [outflux.net]
https://wiki.ubuntu.com/Security/FilesystemCapabilties [ubuntu.com]

While in general this is a good idea, there are issues with it, in
arbitrary order:

- Some currently-SUID programs are aware of them being (potentially)
SUID, and will drop the "more privileged" euid when it is no longer
needed, but they will probably not be aware of them possessing
capabilities. This may result in larger parts of the programs
(sometimes orders of magnitude larger) running with elevated privileges
(or with allowed-to-be-elevated privileges, which is a privilege on its
own and is usable through vulnerabilities that allow for arbitrary code
execution). Let's consider ping, which appears to be the classical
example of "where filesystem capabilities will help" (or so it is
claimed). IIRC, it starts by acquiring a raw socket (NB: of a certain
somewhat-limited type), then drops root privs (if it was installed SUID
root and run by non-root), then proceeds to parse the command-line,
resolve the provided hostname, and so on. If the SUID bit is replaced
with cap_net_raw+ep, as seen in Kees' example above, will ping know to
drop this capability? Hardly. Not without a source code patch.
Besides, dropping the capability might [need to] require privileges
beyond CAP_NET_RAW itself (recall the capability-dropping attack on
sendmail from a decade ago). So does moving from SUID root to
cap_net_raw+ep improve security? Most likely not. On the contrary, it
results in hundreds of lines of ping's code and thousands of lines of
library code (DNS resolver) running with elevated privileges, as
compared to just a few lines of ping.c, which was the case with simple
SUID root. Granted, those "elevated privileges" are a lot less than
root privileges, but they're a lot more than having a single raw socket
of a specific type.

- In some cases, the capability sets being granted are (almost)
equivalent (or expandable to) full root powers. This is seen in:

http://people.fedoraproject.org/~dwalsh/policycoreutils_setuid.patch [fedoraproject.org]

-%attr(4755,root,root) %{_bindir}/newrole
+%attr(0755,root,root) %caps(cap_audit_write,cap_setuid) %{_bindir}/newrole

-%{_sbindir}/seunshare
+%attr(0755,root,root) %caps(cap_setuid,cap_dac_override,cap_sys_admin,cap_sys_nice) %{_sbindir}/seunshare

This mostly just sweeps the SUID root under the rug, where the sysadmin
will hopefully not see it and thus feel safer. However, it may expose
more problems in the programs if they knew to drop root, but wouldn't
know to drop the capabilities (same issue I described above for ping).

Granted, vulnerabilities of certain classes might become unexploitable
or be partially mitigated. For example, if no direct code execution is
possible (not a buffer overflow, etc.), but "only" privileged access to
an attacker-provided arbitrary pathname is possible, then "newrole"
above would be protected, but "seunshare" above would not (because of
cap_dac_override).

- Completely getting rid of SUID root programs in the default install,
like we did in Owl-current (but without filesystem capabilities!), is a
great idea. It mitigates the impact of possible vulnerabilities in
certain code paths in the dynamic linker, libc, and the kernel.
However, if you have even a single SUID root program left, you do not
achieve this goal. Thus, switching from SUID root to CAP_NET_RAW for
ping, with its tiny and obviously-correct code that used to run as root,
gives you absolutely nothing as long as you keep su and/or sudo
available for invocation (not necessarily actual use) by all users.

For servers, I think people need to reconsider and, in most cases,
disallow invocation of su and sudo by the users. There's no added
security from the old "login as non-root, then su or sudo to root"
sysadmin "wisdom", as compared to logging in as non-root and as root
directly (two separate sessions). On the contrary, the latter approach
is the only correct one, from a security standpoint:

http://www.openwall.com/lists/owl-users/2004/10/20/6 [openwall.com]

(For accountability of multiple sysadmins, the system needs to support
having multiple root-privileged accounts, like Owl does.)

(For desktops with X, this gets trickier.)

You also absolutely have to deal with passwd, which would be another
SUID root program. Like we did:

http://www.openwall.com/tcb/ [openwall.com]

And with all others (e.g., our crontab/at and crond changes). :-)

- Support for filesystem capabilities and extended attributes is still
not mature. Many userspace tools (such as for backup/restore) lack it.

Thus, if you must, it might make sense to use a poor man's replacement,
which will be more reliable. Introduce a sysctl to configure a groups
range to map onto capabilities. With 32 or 64 group IDs allocated for
the purpose, you can have any one capability set.

I briefly experimented with just that on a Slackware 3.1
system with capabilities support patched into the 2.0.x kernel, with the
caps-by-gid changes hacked into the kernel on top of the capabilities
patch on my own. That was in 1998 or so. The conclusion was that
without userspace patches this would achieve too little.

With 1024 or 4096 IDs (or 992 or 4032 with a smarter approach), you can
have any two caps. 32-bit GIDs permit you to have up to 5 or 6 caps
simultaneously in this way. I think that in practice 1 or 2 caps will
be enough; the cases where you'd assign more are typically the ones
where the caps are (almost) equivalent to root anyway.

This is more reliable in several aspects:

* The SGID bit and st_gid are stored/restored by all existing Unix
backup/restore/copy/packaging tools.

* Such programs are easy for a sysadmin to identify with the familiar
options to "find", etc.

* Programs either already know to drop the "elevated" egid or are easy
to teach to do so (and the kernel patch may include logic to drop
egid-granted caps when the egid is dropped). This does not require
privileges on its own. And that fact will not confuse any correct but
old program (no "sendmail risk").

- For ping in particular, we've been considering another approach -
namely, a new socket type (non-raw ICMP, similar to the usual UDP
sockets). This would eliminate the need for ping to run with elevated
privileges, or we could introduce some privilege boundary (SGID to some
sysctl'able ICMP-socket-enabling group) just not to expose potential
vulnerabilities in the added kernel code. We have a Linux 2.4.x patch
and a ping patch to implement this, both by Pavel Kankovsky. It's my
fault this never actually got into Owl (so far); I ran out of time.
Any volunteers to update this to Linux 2.6.x, introduce the sysctl, and
actually make use of it in a distro? Please let me know.

Thanks for reading this far, and I'd appreciate any comments and/or
corrections. Some of the info above might be outdated - e.g., I am not
sure of what current kernels require (or not) to drop capabilities.
(If they no longer require anything extra to drop CAP_SETUID, then
that's a security problem on its own - the "sendmail risk" is back.)

Alexander
Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

BTW Fedora 15 is also dropping SUID, so while Openwall is the only current distro. It's by no means the only one in development. Ubuntu is also removing SUID, but I don't know their timetable.

Re:Dropping SUID doesn't improve security (0)

Anonymous Coward | more than 3 years ago | (#34594808)

I wrote a program once that needed SUID for about a hundred asm instructions.

The program was an implementation of tar.

I needed SUID as chroot() was the fastest way to change the symlink traversal vulnerability.

CAP would be wasted as chroot() is one of those known to grant root power.

Sometimes a little bit of SUID is the easiest way to handle things like these.

Re:Dropping SUID doesn't improve security (1)

solardiz (817136) | more than 3 years ago | (#34598018)

> I wrote a program once that needed SUID for about a hundred asm instructions.

Sure the program may be tiny, but it exposes parts of the dynamic linker, libc startup, and even extra parts of the Linux kernel code for attack. All of these components have historically had vulnerabilities exploitable specifically via SUID programs. The point behind not having a single SUID program in a default install of Owl is primarily to mitigate potential vulnerabilities in those components. I do agree that, as the distro level, it would otherwise be possible to live with a few tiny SUID programs, but the risk with other exposed components is very real - so we avoid it.

> CAP would be wasted as chroot() is one of those known to grant root power.

Right. Red Hat are going to "waste" capabilities like this. We are not doing that (we use SGIDs and changes elsewhere in the system instead). (To be fair, there is a subtle reason why even root-equivalent capability sets may be slightly better than directly running as root when we consider some specific vulnerability classes. This is just too complicated to discuss in a comment like this.)

Re:Dropping SUID doesn't improve security (2)

solardiz (817136) | more than 3 years ago | (#34598148)

> Here's one of the better criticisms of dropping SUID, and it's from an Openwall developer. These criticisms are echoed by almost everyone thinking about removing SUID.

I am glad that you liked my criticism of Fedora's approach, however it appears that you misunderstood me. I criticized their specific approach with fs capabilities, not the idea of getting rid of SUIDs in general. The approach taken by us in Owl (many years ago, but only widely publicized now) and the one being taken by Fedora now are completely different (SGID and changes elsewhere in the system in Owl vs. fscaps in Fedora). The purpose of my criticism was to make other folks, including Fedora developers, consider the issues and the alternatives. It was not to discourage them from taking the move, but rather to give them an opportunity to consider our approach, which we consider to be the better and "real" one.

With our approach implemented in Owl, a used-to-be-SUID program runs SGID to a group dedicated to a certain purpose - e.g., editing a user's crontab. Other parts of the system have been modified such that privileges of that group are sufficient for but can't be expanded further than its intended purpose - e.g., permissions on /var/spool/cron and extra checks in crond (for crontab file ownership and more) are such that a possible compromise of group crontab would not give the attacker almost anything - no ability to edit another user's crontabs without also finding a (second) vulnerability in crond or in system components relied upon by crond. Yes, we could as well not use SGID - just make the crontab program fully unprivileged and the /var/spool/cron directory writable by anyone (the sticky bit prevents messing with another user's existing crontabs). The reasons why we chose to use SGID and a group are: (1) this is needed to prevent some DoS attacks (such as taking up another user's would-be crontab filename) and (2) it is an extra layer of security (so direct attacks on crond are not possible without compromising crontab first). Our changes to crontab/crond have since been adopted by ALT Linux, OpenBSD, and even by upstream ISC (Vixie) cron (but most distros somehow don't hurry to make use of this functionality, continuing to install crontab SUID root...)

Fedora's approach is to replace SUID root with fscaps - that is, the programs are still granted a lot of privilege, just somewhat less than they were with SUID root. In many cases (perhaps even in most, where ping might be the only exception), such capability sets are in fact root-equivalent, so this is sweeping SUIDs under the rug. Also, there's no second layer of security. See the difference?

Re:Dropping SUID doesn't improve security (1)

solardiz (817136) | more than 3 years ago | (#34598178)

> BTW Fedora 15 is also dropping SUID, so while Openwall is the only current distro. It's by no means the only one in development.

Right, however Fedora's approach is (1) completely different and a lot worse than ours (in my opinion, indeed) and (2) either won't result in complete removal of SUID programs or will leave many with root-equivalent capability sets. This means that they will continue to expose the dynamic linker, libc startup, and relevant parts of the Linux kernel to the usual risks associated with SUID root program startup - something that we avoid.

> Ubuntu is also removing SUID, but I don't know their timetable.

They're aware of the drawbacks of Fedora's approach, so they don't hurry to implement it. They're also aware of our proposed alternative. :-)

Openwall site (1)

der_alte (1271174) | more than 3 years ago | (#34598972)

the Openwall website groans and moans imploring for a facelift. it's so poignant..
Load More Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Create a Slashdot Account

Loading...