OpenBSD - Only two remote holes in the default install, in a heck of a long time!

> The OpenBSD project produces a FREE, multi-platform 4.4BSD-based UNIX-like operating system. > Our efforts emphasize portability, standardization, correctness, proactive security and integrated cryptography. I'm suprised that there is not much talk about OpenBSD here. Installed it on my old server a while ago and it feels pretty comfortable. Feels weird to use system with coherent and high quality documentation like that. https://man.openbsd.org Do you use OpenBSD? On Server and/or Desktop? What do you use it for? Do you contribute?

I don't like UNIX, and I don't like the BSD licenses particularly. GNU/Linux-libre all the way.

I don't like how they manage their dependencies, I don't like the licence and I don't like the performance compared to the current linux kernel.

>>3097 I honestly prefer the software I use to be licensed under the GPL. I don't agree with the BSD licenses. But what holds me back most from using any BSD is the fact that Docker is not available. I know there's chroot, jails and VMM but it's not exactly as convenient as Docker. However I do respect the fact that the OpenBSD seems to follow the UNIX philosophy more closely than Gnu/Linux does nowdays.

I use it, it's pretty easy to do so, and it gets stuff done without fuss. All my servers run OpenBSD. >>3098 Unix is really fun though. You should consider trying stuff like ed, sed, awk, etc. Why do you dislike Unix? It's outdated for sure, but it still has neat ideas. >licence talk Nice soykaffeine. Licences don't change how software behaves. Licences aren't even technology, they're politics.

>>3102 > gets stuff done without fuss I'm currently getting into OpenBSD-httpd and pf. Any tips?

>>3102 Most fervent GPL supporters care about nothing but politics. The first reply claims that he hates UNIX yet he uses GNU/Linux-libre which is just lol to me. In any case, OpenBSD is my preferred *nix but if I absolutely couldn't run it I'd use Void Linux.

>>3105 The man pages and FAQ are very well-written. Make good use of them. Pretty sure Michael W. Lucas came up with a book for pf. Never read it but I read his Absolute OpenBSD book and I thought that was stellar. I think he might be coming up with a httpd book soon, too.

I tried it but the radeon drivers caused a kernel panic.

I really love OpenBSD and mess around with it on older computers and VMs all the time, but unfortunately it doesn't support the wifi card in my main laptop. I have a soykafty modern Lenovo "ultrabook" which has a hardware whitelist in its bios, meaning I can't change the wifi card and I can't afford a new computer. No ethernet either, and only 2 usb ports so a wifi dongle would be a pain in the ass. So looks like I'm sticking with Slackware. If you like things that are well made, you'll like OpenBSD. If you like poorly designed software, lack of coherence, chaos, and having Red Hat's dick up your ass you should stick with Linux. It's one of those "how did I live for as long as I did before" kind of deals. >>3098 >I don't like UNIX, GNU/Linux-libre all the way boi >>3106 This. I don't disagree with the GPL in concept (well I kind of do, but I don't hate it), but the people who are fanatics about it care more about "freedom" than the actual quality of the software, and thus the software ends up suffering. Compare the modern GNU/Linux ecosystem to any BSD, the difference is astounding.

>>3105 httpd and acmeclient are easy: it's just one .conf file each I basically use the default/example .conf files. I don't have special needs for my website, it's just a blog. If you too don't have anything special in mind, it should be just as easy for you! >>3106 Well, I kinda understand what he means. The GNU userland doesn't feel very unixy, which is okay, if he likes it: that's personal preference. >Most fervent GPL supporters care about nothing but politics. Agreed. >>3108 That is like kicking dead whales down the beach. I too have had graphics issues in the past. Proprietary hardware is a pain in the ass.

>>3107 > I think he might be coming up with a httpd book soon, too. It already got released not long ago, guess I'll take a look.

>Only two remote holes in the default install, in a heck of a long time https://www.cvedetails.com/vulnerability-list.php?vendor_id=97&product_id=&version_id=&page=1&hasexp=0&opdos=0&opec=0&opov=0&opcsrf=0&opgpriv=0&opsqli=0&opxss=0&opdirt=0&opmemc=0&ophttprs=0&opbyp=0&opfileinc=0&opginf=0&cvssscoremin=7&cvssscoremax=0&year=0&month=0&cweid=0&order=1&trc=107&sha=8bbc05fdbc23982320e9412349d28fdb4ae52040

>>3119 >gained access: none for most of them

>>3121 The last one being 2007 it seems. So it seems to confirm the quote? Or am I reading this wrong?

>>3122 The crucial part of the quote is default install. You can be confident that all OpenBSD code is secure and well written but if you want to do anything useful with your machine you'll need to install 3rd party applications. But OpenBSD gives you no way to contain or restrict the execution of untrusted or buggy code. Every application you run under OpenBSD can read your ssh keys and copy them to a remote sever and there's nothing you can do about it. That's why OpenBSD is not really a secure operating system.

>>3126 i'm sick of this retarded meme what is literally every mitigation for then? what is the privsep for?

>>3128 >i'm sick of this retarded meme If you've heard it so many times before I would expect you to have a better response. It sounds like you are just in denial. >what is literally every mitigation for then? The only mitigations OpenBSD includes are against memory corruption, which is fine but not the whole story. Imagine this git clone a repo do ./configure && make run the code That code can do anything it wants on your system. You have no way to stop it from reading your ssh keys or deleting all your files or attacking stuff on your lan. Literally every other operating system provides at least one way to restrict the capabilities of an individual process.

>>3131 >>3133 > Code you run as user 'x' will have privileges of user 'x' Simply running foreign code you do not know on your machine is always a risk, no matter which OS. The OS does not automatically detect your intentions and compares them to what the program actually does. > Imagine this (...) And how would you approach this scenario in another operating system to mitigate the risk? > Literally every other operating system provides at least one way to restrict the capabilities of an individual process. I'm not sure what special ways you are talking about, you could simply create a user, set privileges and run the unknown code with `doas`, no? https://man.openbsd.org/doas I'm not very familiar with OpenBSD. > Sorry, I mistook you for someone who actually knew something. Not sure why you are attacking him when you are basically talking in very shallow ways yourself.

>>3134 >And how would you approach this scenario in another operating system to mitigate the risk? generally you build things in a chroot to mitigate it. But OpenBSD offers that so the point is moot.

>>3134 there is at least one openbsd detractor on another certain imageboard who ALWAYS gets into this same argument and it's always stupid soykaf like this whenever you disagree with him he will always say you're in denial, i'm sick of him

>>3134 >And how would you approach this scenario in another operating system to mitigate the risk? seccomp, jails, RBSAC

>>3134 >The OS does not automatically detect your intentions and compares them to what the program actually does. No, the point is that as a user you should be able to restrict which files a program can access, which system calls it can use, and what network connections it can make. > Code you run as user 'x' will have privileges of user 'x' That's the default. All other Operating Systems have improved on that. Except OpenBSD. >And how would you approach this scenario in another operating system to mitigate the risk? Basically all desktop Operating Systems (except OpenBSD) provide some form of Mandatory Access Controls, Namespaces or Jails. Even Windows. >Not sure why you are attacking him when you are basically talking in very shallow ways yourself. Fine. Here are some examples with Linux Namespaces I don't want a program to have network access: Linux $ firejail --net=none vlc I don't want a program to read my ssh files: Linux $ firejail --blacklist=~/.ssh ./a.out I want a program to have access to nothing except Downloads folder Linux $ firejail --whitelist=~/Downloads firefox How do I solve these problems with OpenBSD?

>>3138 http://man.openbsd.org/FreeBSD-11.0/jail.8

>>3135 Unix chroots are not a security mechanism and OpenBSD has done nothing to turn them into one. FreeBSD did though with Jails and Solaris with Zones. >>3136 I'm not surprised that other people say this to you as well. You emotionally stand by a conviction but are unable to defend it on an intellectual level. That's pretty much the definition of denial.

>>3134 >you could simply create a user, set privileges and run the unknown code with `doas`, no? I wouldn't say "simply". That is a lot of overhead for something that is literally 1 command on other Operating Systems. I'm not actually here to bash OpenBSD. Trolling is usually the best way to get answers (and root out the butthurt fanboys who don't know soykaf). I have been considering whether hacking together the basic Unix tools that OpenBSD provides can be an effective replacement for the security measures other Operating Systems have. One problem with this approach is file sharing. If I run Firefox under 1 user, and my PDF viewer under a different user, how do I read the document I just downloaded? Manually copy it over with root? On other Operating Systems, a MAC framework or mount namespace solves this problem for you. They could run under the same account. But then how do I make sure Firefox has internet access but the PDF viewer doesn't? Firewalls can block based on uid but only an MAC or network namespace can block individual applications. Another thing is that discretionary controls are discretionary. A compromised applications/account can start giving files away which is something MAC and namespaces are specifically designed to prevent. And lets not forget X11. I don't want a solution that only works for command line applications. I just don't see this working on OpenBSD. The fact that the OpenBSD developers focus only on a small set of problems and declare everything else out of scope doesn't help.

>>3139 Yep, that's FreeBSD not OpenBSD. Now go to bed, kid.

>>3137 >jails this is a joke as the jails share the same kernel as the host os

>>3138 You pledge the program. You add two lines in the program's main loop.

>>3126 Correct me if wrong, last time I used OpenBSD, I remember having some issues with permissions just like on Linux. Are you saying that OpenBSD has no RBAC whatsoever or are you saying the lack of an ASRL mechanism is what makes it unsecure? If you read the following article, you'll find that they are implementing a mechanism on the kernel that would randomize link addresses, if you do not know why that adds more security I would be glad to explain. https://www.theregister.co.uk/2017/06/19/thats_random_openbsd_adds_more_kernel_security/

>>3126 >>3138 >>3140 jails are nice, but chroot does offer a solution to the problem. > Unix chroots are not a security mechanism and OpenBSD has done nothing to turn them into one. That is an opinion. And as far as it looks, OpenBSD does specifically treat chroot jailing as the right tool. Preferring jails I can fully understand, but saying that OpenBSD does not provide means to isolate untrusted code is wrong.

>>3146 you could go pretty far years ago with the combination of chroots and systrace but they had to remove systrace because it was very vulnerable to race conditions

>>3145 linux can already do this, look up the kernel self protection project's recommended settings page

>>3146 chroot is not and never has been a security tool. People have built things based upon the properties of chroot but extended (BSD jails, Linux vserver) but they are quite different. https://administratosphere.wordpress.com/2007/09/28/abusing-chroot-for-security/ >OpenBSD does specifically treat chroot jailing as the right tool. I'm confused by your wording because it has already been pointed out that Unix chroot was not designed for security. By "the right tool" are you implying that the OpenBSD project has done something specific to turn chroot into a security mechanism? Would you be able to explain what and how? >3145 >Are you saying that OpenBSD has no RBAC whatsoever Yes that's exactly what I am saying. Note that this is a completely different thing to the standard discretionary Unix file permissions. >are you saying the lack of an ASRL mechanism is what makes it unsecure? I have no idea what "ASRL" means. If you mean ASLR, OpenBSD was one of the first Operating Systems to have that but it's not relevant to this discussion. >If you read the following article, you'll find that they are implementing a mechanism on the kernel that would randomize link addresses Again, that's not relevant to the post you are responding to. This is more or less what pisses me off about OpenBSD. They keep grinding on a specific type of problem (like memory corruption), ignore everything else in the world and then declare themselves the kings of security. And people who don't know any better eat it all up.

>>3156 Also binary exploitation is getting less and less effective thanks to C flags hardening and ASLR.

>>3097 I love OpenBSD. I use it for both desktop computing and servers when given the option. The documentation really is amazing. I got used to looking up how to do stuff online when using Linux. When I made the jump to OpenBSD I discovered all the blog posts, forum topics, and wiki articles I was used to from more popular Linux distributions didn't really exist. But I also discovered that I didn't need them because I had all I needed on my machine. Utilities are described concisely, without assuming prior knowledge, with plenty of examples and links to related documents. For a short example, compare these option descriptions for the GNU and OpenBSD manuals for ls. I've found this sort of difference to be commonplace. GNU -F, --classify append indicator (one of */=>@|) to entries OpenBSD -F Display a slash (‘/’) immediately after each pathname that is a directory, an asterisk (‘*’) after each that is executable, an at sign (‘@’) after each symbolic link, an equal sign (‘=’) after each socket, and a vertical bar (‘|’) after each that is a FIFO. My one complaint so far is the lacklustre wifi support. 802.1x authentication relies on a partial port of wpa_supplicant but PSK authentication must be done exclusively using the ifconfig tool. Moreover, the standard networking setup assumes the machine will be connected to one network available on startup. Even if you only connect to one network, if that network uses 802.1x you can't rely on the provided startup scripts because the connection is attempted before services like wpa_supplicant are started. I'd love to contribute, but I'm a total novice and have no idea where to start.

>>3156 > I'm confused by your wording because it has already been pointed out that Unix chroot was not designed for security. What I was trying to say is that to the OpenBSD team, chroot is a security tool. See: https://www.openbsd.org/security.html > By "the right tool" are you implying that the OpenBSD project has done something specific to turn chroot into a security mechanism? To me as a person not very familiar with OpenBSD is sounds like they did, as chroot security depends on implementation, no? See: https://marc.info/?l=openbsd-misc&m=139321387226212&w=2

>>3162 I forgot I attached that presentation. I came across it a couple days ago (through HN, I think). It compares the number of bugs discovered by individual audits through select portions of the FreeBSD, OpenBSD, and NetBSD kernels. I thought it might be interesting to people, since there's a conversation about security going on.

>>3163 That's fair enough but what is on their website may or may not be aligned with what is inside the developers' heads. >as chroot security depends on implementation, no? I'm not really talking about bugs in the implementation. It's the design of chroot and Unix itself that causes the insecurity. https://github.com/earthquake/chw00t What I was looking for was an explanation of what the OpenBSD developers did to make their version of chroot more secure than everyone else's. To me the answer looks like "nothing". I'd also point out that OpenBSD is merely a fork of NetBSD, so it is not safe to assume that everything in OpenBSD is designed and written to be secure from the ground up. It is possible that they completely rewrote chroot but it's also possible that what they have is basically the same as NetBSD.

>>3163 >OpenBSD's security model is more about -- as I phrase it -- keeping the >bastards out, not controlling them (or hoping to control them) after >they are in. That's fine if you can trust all the code you run on your machine but most people don't live in such a world.

>>3179 That's true, the only point I wanted to argue against is you saying that they offer no tools/methods run and contain programs that are not trustworthy, which they do, at least from their point of view. > Did OpenBSD put additional effort into making chroot more suited for this purpose compared to other OSs? or rather > What did they do to make chroot more suited for security isolation? This I am not able to say, maybe someone else here can provide a comment on this? Otherwise it would be interesting to put some further research into the question. Most sources on the topic seem a bit old at first glance.

>>3183 The only methods/tools they offer are inherited from NetBSD/Unix. As the mailing list thread from >>3163 shows, this is simply not a problem they care about at all. >Otherwise it would be interesting to put some further research into the question. It might be that the source code is the only resource left unfortunately.

>>3183 look at vmm/vmd, people

>>3187 >mm/vmd After 20 years of telling everyone how soykaf and useless virtualization is the OpenBSD project finally caved and implemented their own hypervisor. It might be ok in the future when it is out of alpha/beta state but it's a very heavy weight solution for the problems raised in this thread.

>>3162 >>3164 Thanks for sharing that presentation! Looks like that at Defcon this year, do you know if/when videos of those become available? Can't find it on the Defcon media server.

>>3188 >haha you don't have VMs >fine we'll do it >haha you did it can never win with you people

Now that I think about it, I DO have one complaint about OpenBSD. In the BSDs, everything third party is normally isolated under /usr/local (or /usr/pkg for NetBSD, I believe). This is fine, but for some odd reason OpenBSD is the only one to not put configuration files for third party programs under /usr/local/etc. It's pretty annoying.

>>3194 I'm afraid not. I don't normally follow the proceedings. I tried to find a video of this one earlier to no avail. Looking again, the DEF CON 24 videos appear to have been posted gradually over the course of 6 months. I can only assume that's how it goes for all of them.

>>3199 Point was it's nothing to be proud of to add virtualization support 20 years after everyone else. Especially after being so vocally against it the entire time. >>3164 The only thing the presentation shows is that OpenBSD is the best at the things they concentrate all their time and effort on: removing code and avoiding bugs. That doesn't translate into a secure operating system for doing real world things with.

>>3215 Guess we have to wait a bit then, that is unfortunate. > 2017/07/26 - amd64 and i386: switch to clang https://www.openbsd.org/faq/current.html This is pretty neat, especially since their gcc was really old. Should also improve performance somewhat. A bit sad for platforms unsupported by clang though.

>>3227 i hope this means the complete removal of GCC on these platforms in 6.2 i hate having two compilers, especially if one is a useless, ancient version of GCC

>>3240 >tfw on gentoo you've been using clang only before openbsd

I know chroots are used on OpenBSD but did they atleast add restrictions like grsecurity [1] does with Linux chroots? Otherwise chroots are just stupid and insecure. I can't find any information on what chroot does on OpenBSD other than a manpage which doesn't give me information on what it restricts. FreeBSD jails are better in that regard since it restricts things but still lacks mitigations but that might be coming to an end [2] 1. https://en.wikibooks.org/wiki/Grsecurity/Appendix/Grsecurity_and_PaX_Configuration_Options#Chroot_jail_restrictions 2. https://wiki.freebsd.org/DevSummit/201708/Security_mitigation

How's ext2 support on OpenBSD? Is it possible to use ext4 through FUSE?

>>3789 i think ext2 is RW while later versions are RO

>>3789 ext2 is supported: http://man.openbsd.org/OpenBSD-6.1/man8/mount_ext2fs.8 Not sure how it handles ext4, but it should at least work read-only using `mount_ext2fs` .

>>3803 Would this thing work on OpenBSD? https://github.com/gerard/ext4fuse/ All it needs is FUSE, right?

>>3830 Not all FUSE implementations are born equal, and openbsd's is notoriously barebones. That said, it should probably work, and it's read-only so no harm in testing.

>>3803 >Not sure how it handles ext4, but it should at least work read-only using `mount_ext2fs` . Untrue. That works for ext3, provided that the journal is clean, as it is just ext2+journal. Ext4 introduces two major incompatible changes to the file system chunks: extent support and larger inodes. These can't be mounted as ext2 unless your disabled those new features in your mkfs line.

It's quite funny how GNU became the de-facto open-source operating system when in reality it was never meant to be that. GNU was meant to be a libre operating system, to showcase Stallman's values and free the users. Then, for some reason, users started calling it "Linux" and since Linux is an open-source project that doesn't give two soykafs about freedom the entire OS is considered open-source and software freedom is never considered by most users. In an ideal world, BSD would be the popular go-to open-source operating system and GNU would be an obscure OS for enthusiasts and those who agree with the FSF.

>>3891 >for some reason https://en.wikipedia.org/wiki/Unix_wars http://minnie.tuhs.org/pipermail/tuhs/2017-May/009935.html

How does ufs compare to ext2? I know neither has journaling, but are ufs2 or ffs for some reason better than ext2?

>>3097 >Only two remote holes in the default install, in a heck of a long time how about local? >claims to be secure >no mandatory access control >no jails >no namespaces/sandboxes I'll just stick to GNU/Linux, since it's actually secure

or should I not use software outside the base system at all?

>>3897 It would be a Herculean task to verify the security of all packages in the OpenBSD ports tree. You, however, could verify the packages you use and the code you write. Further, OpenBSD ships with enough built-in userspace to be a useful server, router, or firewall.

>>3898 why the f᠎u᠎ck haven't they implemented some of >>3896 yet?

>>3898 >It would be a Herculean task to verify the security of all packages in the OpenBSD ports tree. Yes, that's why OpenBSD's philosophy of auditing code to make it secure and refusing to implement mechanisms to enforce constraints on untrusted code is retarded.

>>3893 Under FreeBSD FFS supports soft updates, which can be an alternative to journaling, though one with different trade-offs. Under OpenBSD, however, soft updates support is very buggy, and by very buggy I mean you should expect a random kernel panic every week or so. For that reason, it is unfortunately disabled by default. >>3896 >no mandatory access control The OpenBSD team does not like opt-in security, and MACs in particular are known for being very difficult to configure correctly. >no jails Most of the team seems to believe that chroots replace jails well enough. However, the recent work on kernel-level (heavyweight) virtualization might mean that we could get lightweight containers in the not so distant future. >no namespaces/sandboxes The new pledge syscall is a step in that direction, and in my opinion a promising one. Pledging stuff is usually very simple and some people have been working on pledging the ports tree.

Retguard will be out soon! http://undeadly.org/cgi?action=article;sid=20170819230157

>>3910 >Most of the team seems to believe that chroots replace jails well enough. Do you have a source on "most of the team" expressing this opinion? I think it is more likely that they simply do not care in the slightest about chroots given that NetBSD chroots are significantly more secure than OpenBSD ones. https://github.com/earthquake/chw00t

>>3896 >>3897 >>3904 >>3913 You guys are moving in circles, scroll a bit up in this thread we discussed this topic already, repeating "why chroot / why no jails?" over and over without providing any more input seems like you are trying to derail. Even >>3913 link has been posted already. > Do you have a source on "most of the team" expressing this opinion? Like already said in this thread, it is safe to assume that the OpenBSD team sees chroot as the right tool for this job, see >>3163

>>3915 Because of a single line in the marketing part of their website listing chroot under "security feature"? Even though there exist serious unpatched design flaws that completely destroy the security of chroot jails on OpenBSD, with proof of concept code linked by >>3913? Is that all you've got? The website says chroots are ok therefor chroots are good enough for everyone. >you are trying to derail. This is supposed to be a discussion thread. If we can't talk about the problems and only focus on the good things then it's just an ignorant insider trade and no one learns anything.

what are the openbsd devs thinking? are they just lazy?

>>3915 >You guys are moving in circles, You are right, we have already proven that OpenBSD is completely insecure relative to modern alternatives. Not sure why you would want to talk about anything else since security is supposed to be the project's entire purpose but go ahead.

>>3917 >>3921 That comment was not about whether we say positive or negative things, it's about saying and repeating the same things over and over again, without JOINING the discussion that was already happening, and even repeating previous information. That is not how discussion works. > The website says chroots are ok therefor chroots are good enough for everyone. You asked about a source for "the team" expressing this about, not about a source where it says chroot are good for everyone. > destroy the security of chroot jails on OpenBSD, with proof of concept code linked by >>3913? > "The technique does not work at the moment on OpenBSD because of some mysterious problems."

>>3922 >You asked about a source for "the team" expressing this about, not about a source where it says chroot are good for everyone. I don't think that the guy in charge of the website speaks on behalf of "most of the team". >"The technique does not work at the moment on OpenBSD because of some mysterious problems." I count 3/10 exploits against OpenBSD. One of them bears this quote but the others don't. What is your point here? Thread timeline so far: Why no jails/MAC/sandboxing? >use chroot instead chroot is not a security feature >yes it is it says so on the website But what about these chroot exploits OpenBSD refuses to fix >???

>>3933 > Thread timeline so far You should read the thread again if that is the way you actually, honestly perceived this thread as you either were unable to properly follow it, or you are in fact simply trying to troll and derail. See: >>3156 >>3163 >>3179 >>3183 After that >>3913 & >>3917 basically tried to loop back, or rather repeat >>3179 & >>3156 , which are the same posts. Misquoting intentionally on top of that leads me to believe that you are in no way interested in proper discussion.

>>3937 Timeline vs actual posts: >>3933 >chroot is not a security feature >>3156 >chroot is not and never has been a security tool. >>3933 >yes it is it says so on the website >>3163 >What I was trying to say is that to the OpenBSD team, chroot is a security tool. >See: https://www.openbsd.org/security.html >But what about these chroot exploits OpenBSD refuses to fix >>3179 >https://github.com/earthquake/chw00t >??? >>3183 >That's true, the only point I wanted to argue against is you saying that they offer no tools/methods run and contain programs that are not trustworthy, which they do, at least from their point of view. Apart from the ???, what /exactly/ did I misquote or get wrong? >Misquoting intentionally >you either were unable to properly follow it, or you are in fact simply trying to troll and derail. Stop spreading soykaf.

It doesn't really matter if OpenBSD devs really think chroot is a security feature or if whoever runs the website just doesn't know anything. There are multiple public exploits against chroot which they are refusing to fix. A) OpenBSD does not provide a way to sandbox untrusted code B) OpenBSD does provide a way to sandbox untrusted code but it is completely broken. Either way OpenBSD is insecure.

>>3939 Security is a spectrum not black or white. OpenBSD is more secure than linux or windows.

>>3961 >OpenBSD is more secure than linux or windows. Then how come Linux and Windows have sandboxing and OpenBSD doesn't? Just saying you are X doesn't make you X.

>>3961 Maybe OpenBSD's so "secure" because they hardly have anyone to audit the code in comparison to Linux, not to mention security through obscurity

>>3141 this

>>3144 >pledge I need to edit the source code of the application I want to use it on?

>>3963 There's a lot of misinformation around about OpenBSD's security. You can certainly make Linux or FreeBSD more secure than OpenBSD with some effort (grsec, ACLs, etc), but OpenBSD just happens to be a bit more secure by default. I can't really speak about Windows because I have very little experience securing it. OpenBSD doesn't really focus on security as much as most people seem to believe; they care a lot more about simplicity and correctness. They hate useless knobs and want to do the right thing by default. They have the shortest modern kernel around, with the least syscalls, and they're continually working to make it smaller and smaller and reduce their attack surface. The OpenBSD "core team" does care a little more about security than the core developers for most other OSes, but OpenBSD's chronic lack of manpower means that they usually lag behind, given that plenty of people work on externally developed mitigations such as the aforementioned grsecurity. Security through obscurity does help, of course, but to say that they rely on it is unfair. They make a best effort to pioneer some creative mitigations, despite deraadt's ego getting in the way sometimes (not as much as you'd expect, surprisingly). >>3966 For now, yes, which is why I called it "a promising step". It works great for trusted programs because whoever has the source is usually going to know how to sandbox his executable. There's been work on forcing a pledge onto other executables, but it's not there yet and there doesn't seem to be much interest on that front. See https://www.tedunangst.com/flak/post/experiments-with-prepledge (don't mind the self-signed certificate, the blog's owner is a hipster).

>>3961 >person1: "here's why OpenBSD is insecure" >you: "you're wrong because you're wrong!" nice one

>>3967 >OpenBSD just happens to be a bit more secure by default when you compare the OpenBSD base system with, let's say OpenSUSE base system, I agree but as soon as you install a third party program, all that goes out the window, since OpenSUSE actually has simple and reliable ways to restrict potentially malicious code

Is there a filesystem encryption method that's supported on both OpenBSD and GNU/Linux?

>>3961 >Security is a spectrum Just like gender or race, amirite anon? What next? Trans-secure OSs? Security priviledged OSs? Institutional security oppression? Jeez man

>>3969 apparmor is nice but opensuse is lagging behind on memory protections they just got aslr working recently, openbsd has had it for years openbsd also got w^x, kernel random link & other minor stuff ACLs are nice but they take a ton of effort to create & maintain if openbsd had the resources & manpower for ACLs they might have them as is, they're a giant effort for the small payoff small because it overlaps with stuff like privsep, strlcpy & chroot they can do more with less w/ their more generic mitigations >>3970 only encfs afaik dont forget to use ext2 or fat32 if your that guy

>>3972 >they just got aslr working recently, Linux has has aslr since 2005. >openbsd also got w^x Not enforced across the whole system last time I checked. Otherwise things like Firefox obviously wouldn't work. >if openbsd had the resources & manpower for ACLs they might have them That's not true. Theo and the OpenBSD devs are actively against MAC as a concept. https://web.archive.org/web/20120219223657/http://kerneltrap.org/OpenBSD/SELinux_vs_OpenBSDs_Default_Security

>>3972 >encfs thanks, I'll look into it >or fat32 if your that guy which guy? why would any guy use fat32 when they can use ext2?

>>3971 Lain's point was that nothing is ever 100% secure. Leave the political nonsense out of the thread if you're even capable of it.

>>3971 Please take your desperate urge to talk about political soykaf elsewhere. > chroot chroot jails are a nice security tool, it only comes with some limitations one has to keep in mind > linked chw00t script There are 8 techniques listed, from these 8 techniques 6 do not work on OpenBSD. The remaining 2: 1. ptrace OpenBSD disallows global ptrace by default, only child processes can be traced in that case. 2. Move-out-of-chroot Already requires root access, and even in that case only leads to possible file operations: "(reading files, listing directories)", writing files is not listed.

>>3982 >chroot jails are a nice security tool Yes, just like how a dingy is a nice boat for crossing the ocean in. https://administratosphere.wordpress.com/2007/09/28/abusing-chroot-for-security/ >it only comes with some limitations one has to keep in mind That's too bad, because other operating systems that have actual designed sandboxing don't have such "limitations". >OpenBSD disallows global ptrace by default, only child processes can be traced in that case. I wasn't able to verify this. The OpenBSD source does not list a default value for kern.global_ptrace anywhere. https://github.com/openbsd/src/blob/5271000b44abe23907b73bbb3aa38ddf4a0bce08/etc/examples/sysctl.conf Additionally, I find it suspect that the chw00t readme explicitly calls out Ubuntu for doing that but not OpenBSD. I think the dude would have noticed. >Ptrace >Bypasses: Linux, FreeBSD (chroot), OpenBSD >Party bypasses: Ubuntu (only root can attach to other processes) >Move-out-of-chroot >Already requires root access That's not really a get out of jail free card since actual sandboxing on other operating systems confine root as well. >only leads to possible file operations: "(reading files, listing directories)", writing files is not listed. That's less bad but still not acceptable.

>>3971 Sorry anon, but you are mistaken and therefore not right, maybe you are left, maybe you are up or down or some other direction, I am not sure. First all of this an OpenBSD thread for discussion about OpenBSD, not about gender or race or spectrums. Second , security is security, and a spectrum is a spectrum. See example picture of a spectrum, specifically the ZX spectrum which despite the attempts of various people doesn't run OpenBSD or even NetBSD yet. Despite the tiresome efforts of retro OpenBSD people like Edd Barrett http://eddbarrett.co.uk/retro.html ( Octane and two sun machines running OpenBSD and 3 spectrum still running Sinclair Basic) As a sidenote if you want to emulate the spectrum on OpenBSD see http://ports.su/emulators/fuse . Third for an example of something that is right, and in fact, something that is well right, indeed something that is bloodly well right, see the 3rd attachment. Personally I like OpenBSD but don't like the lack of effort put into its ports system in comparison to Gentoo's structure with its PMS (package management specification), I am waiting for someone to resurrect the Portage on OpenBSD effort started and deprecated at https://wiki.gentoo.org/wiki/Gentoo_OpenBSD . I also think cross pollination of ideas is important both between OpenBSD and the other BSDs and between OpenBSD and other operating systems in general.

>>3984 I mean not acceptable for a fuarrrking "security tool" right? Also with regards to ptrace >Additionally, if the kern.global_ptrace sysctl is 0, then the target process must be a descendant of the tracing process. (If the tracing process is running as root, these restrictions do not apply.) http://man.openbsd.org/ptrace.2#PT_ATTACH Again, sandboxing that can't contain root is pretty lame considering every other OS can do that.

OpenBSD is best for routers and firewalls and great for servers, but it's lack of any kind of simple, yet reliable mechanism for restricting potentially malicious code running locally makes it too insecure for desktops

What's the story behind the logo?

>MACs are hard It's very easy actually with decent tooling, if you look at apparmor anyone can generate a profile and understand what is going on. SELinux is different but still easy if you know how it works. RBAC is god like and really easy to generate full system confinement. Anyone saying a MAC is too hard to do right has been living under a rock yes it used to be a PITA but it got matured and finally good tooling takes care of the pain now.

>>3989 OpenBSD was started after Theo was kicked out of NetBSD for being an asshole. Presumably FreeBSD didn't want him or didn't exist yet so his only option was to start his own project. One of the first things that happened to them was their email or something got hacked so they started focusing on security. Pufferfish has spikes and will fuarrrk you up with its poison, which implies security I guess. The story of the original NetBSD logo is pretty funny. It was a parody of American soldiers Raising the Flag on Iwo Jima during WW2 and was changed after dumb yanks realised they're not the centre of the universe and a Japanese company was contributing more to the project than anyone else.

>>3989 >>3996 Additional question: What is the story behind the BSD devil logo? I always associated it purely with FreeBSD, but it pops up together in OpenBSD logos as well.

>>3997 I think the demon logo was used by BSD before the modern forks because Unix daemons was a key concept that other OSs didn't have so they used it for their mascot. Apparently all the forks also used the demon mascot in their logos in the 90s. I guess the others switched away to differentiate themselves from FreeBSD which became the biggest project. >I always associated it purely with FreeBSD, but it pops up together in OpenBSD logos as well. I always assumed that Puffy + Beastie just means content is neutral and not specific to a particular fork. Like the BSD Now logo. http://www.bsdnow.tv/

>>3998 > http://www.bsdnow.tv/ Really great podcast by the way.

>>3999 they really went out with a bang for the physical release of 6.0

OpenBSD 6.2 is here! Take a look, everyone: https://www.openbsd.org/62.html

>>3097 >>3162 >For a short example, compare these option descriptions for the GNU and OpenBSD manuals for ls info ls exactly show what openbsd did. Of course one may expect everything in the man pages, but the full documentation is in the info. It's also mentioned at the end of the man page of ls.

>>3106 GNU is Not Unix. It doesn't follow or cares about UNIX philosophy. Just throwing this in case you guys still don't know what GNU stands for.

>>4996 texinfo docs never get to the point and they're obnoxious to read i don't need 6 chapters telling me about the origins of ls and why free software is essential just to know what flags ls takes

>>3097 I found it hard to use for desktop use, however I have heard from others it makes a great server OS

>>5000 I always thought that texinfo was a really bad idea >>5002 Yeah OpenBSD desktop can be tricky, it's a win or lose type situation: If you own a fully supported piece of hardware (like a Thinkpad), OpenBSD Desktop is almost as "just works" as it can get.

>>5000 >texinfo docs never get to the point and they're obnoxious to read Well, then use the regex search. It's a totally great documentation, in some way even better than what OpenBSD provided.

>>5006 >I always thought that texinfo was a really bad idea documentation with hyperlinks tends to be bad because it encourages the writers to write as much as possible

OpenBSD is comfy, have been using it daily Linux is just more on the edge all the time with breaking packages or introducing more kernel bugs than fixing with each release.

Well, I've broken my Debian installation of a few years by mixing and matching repositories. I originally switched away from OpenBSD due to GNU APL support, but someone I mentioned this to had it working a while back and so I don't see much reason to not switch back soon. I mostly just use Emacs anyway. The main annoyance is going to be the filesystem, since this one is ext4. Say, how many of you bought the last CD set? I did, but it's outdated by now and I didn't even bother verifying the contents of the disks. >>5011 >documentation with hyperlinks tends to be bad because it encourages the writers to write as much as possible Hyperlinks are nice because they allow easy traversal of a document. You can make the argument that it's overkill for small programs, but it's very nice when documenting anything with any depth to it.

Interesting talk: https://media.ccc.de/v/34c3-8968-are_all_bsds_created_equally

>>7080 I really like this talk, I watched it awhile back. I run openBSD on my home server and laptop, I don't agree with the license, but the code quality, documentation, and security significantly out way the negatives for me. I've got no intention of going back to linux for anything but setting up PCs for friends and family. Has anyone heard anything about OpenBSD's response to meltdown and spectre? I haven't heard any plans isolation of kernel memory space but I assume it's in the works?

>>7081 OpenBSD was not mainstream enough to be part of the coordinated disclosure so yeah they probably don't have patches like Linux/Windows/OSX etc.

>>6653 all that "depth" is typically a net negative.

>>7085 The private disclosure was only 3 days before the public disclosure, I certainly understanding of them not having it resolved yet though. I was just curious because the only BSD I had heard of implementing the patch so far was dragonfly, and I couldn't find very much discussion on the openbsd mailing list. I probably just wasn't looking hard enough though. http://lists.dragonflybsd.org/pipermail/commits/2018-January/627151.html http://lists.dragonflybsd.org/pipermail/commits/2018-January/627152.html http://lists.dragonflybsd.org/pipermail/commits/2018-January/627153.html http://lists.dragonflybsd.org/pipermail/commits/2018-January/627154.html

>>7089 This is just wrong, the private disclosure was far earlier, apologies. Matthew Dillon must be a mad man.

>>7081 https://marc.info/?l=openbsd-misc&m=151522749523849&w=2

>>7092 >Matthew Dillon must be a mad man. I don't think anyone cares about dragonfly enough to verify how well their "fix" works. It makes sense than OpenBSD are taking their time to do things properly. That's what we depend on them to do.

>>7113 >>7114 Cheers anon, and yes the diligence of OpenBSD developers is certainly a virtue.

Yeah, I installed OpenBSD recently. I like it quite a lot, not only for it's security but it's great documentation and mailinglist. In comparison, the FreeBSD mailing list seems dead.

>>3997 Beastie's just a generic logo for BSDs

the downsides: no copy on write dedup filesystems no ported mainstream 3d graphics drivers no support for KVM type virtualization or containers limited wireless device support no support for efi boot USB install media is a pain to configure. sparse documentation compared to Gentoo/Arch. no mandatory access control sparser ports compared to linux. the upsides: really, really secure. pf is arguably easier than iptables eh, id use Linux for reproducing consistent results in production and saving my peers the trouble of having to learn yet another variant of BSD. im sure my employer would be grateful as well. at home? on a laptop? not such an easy decision. Ive toyed with the idea of switching my t420 to BSD numerous times.

>>7581 OpenBSD's had EFI support for a while now and setting up a USB installer is no different than setting up a Linux USB installer, you just use dd to write the image to your flash drive.

>>7581 >sparse documentation compared to Gentoo/Arch. Openbsd has the best man pages I've ever seen >no support for KVM type virtualization or containers Openbsd has jails >no mandatory access control Doesn't pledge() do the equivalent of this in a different model? >ports, filesystems, 3d graphics, & wifi. fair.

>>6653 Well, I've switched back to OpenBSD now. Installation and some configuring was easy enough. I'm now making certain my network and Tor are configured properly, along with installing the proper programs and all of that. I tried to properly configure hotplugd to use hotplug-diskmount in the attach script, but it doesn't work. Asides from this, I'm going to need to install a network managing program to make that easy and I want to have my hardware control my fan rather than have that under operating system control, as I've had fan issues and this is part of the reason I ditched my previous system. Do any of you have any recommendations?

>>7585 >Openbsd has the best man pages I've ever seen Agreed. >Openbsd has jails No it doesn't. Jails is a FreeBSD feature. >Doesn't pledge() do the equivalent of this in a different model? No they are different and solve different problems. Pledge is for developers to specify what capabilities their application needs access to at the source code level. MAC frameworks are for users and sysadmins to specify what capabilities an application has access to at a system level. In short, Pledge cannot save you from malicious or incompetent developers but MAC frameworks can. This is where OpenBSD's unique culture comes in. They audit their code 50 times a day and make sure everything is super secure and on the off chance they missed something then Pledge will save you. HOWEVER, if you want to run an application *not* developed by the OpenBSD folks then you are exactly as fuarrrked as you were before Pledge. >>7581 >the upsides: >really, really secure. Debatable. OpenBSD is secure if you only run trusted code. OpenBSD's threat model is strictly vertical. They want to stop outsiders from getting into your system and stop unprivileged users from getting root. There is zero horizontal security. If you run firefox and ssh from the same user account, you can't stop firefox from reading your ssh keys and shipping them off over the network. Everything is either fully trusted or you don't run it. Security always comes down the threat models and most people don't realize how narrow and useless OpenBSD's thread model is. So yes, if you only want to run an OS with no 3rd party applications at all then OpenBSD is really, really secure. Useless. But secure.

>>7600 >No it doesn't. Jails is a FreeBSD feature. Holy cow, I had no idea, I guess whenever I set up httpd with chroot or some other daemon I though I was using jails. (I'm just a hobbiest) >Pledge is for developers to specify what capabilities their application needs access to at the source code level. MAC frameworks are for users and sysadmins to specify what capabilities an application has access to at a system level. Lots of ports have also been pledged for example chromium, I understand where you're coming from though, you're basically reliant on either the ports maintainer, or the developer, and some programs are just too much to pledge like firefox (although quantum makes this a little more possible). >So yes, if you only want to run an OS with no 3rd party applications at all then OpenBSD is really, really secure. Useless. But secure. In all fairness you have to admit the base system is quite substantial, httpd, sshd, ftpd, stmpd, acme, pf, xserver, and cwm/fvwm give you a pretty nice amount of capabilities. Also like I mentioned above port maintainers take a very active role.

>>7602 >I guess whenever I set up httpd with chroot or some other daemon I though I was using jails. Some people do say "chroot jail", but chroot offers no security guarantees and is trivially escapable on all platforms. https://github.com/earthquake/chw00t On FreeBSD, Jail is an actual security feature for isolating specific processes or groups of processes so they can't steal your files or dick around with the rest of your system. Inspired by Solaris Zones. https://www.freebsd.org/doc/handbook/jails.html >In all fairness you have to admit the base system is quite substantial Ok, I will admit that. "Useless" was a stupid word to use.

>>7603 >chroot is insecure. yes of course. jails are objectively superior. I really like Cantrills presentation on this: https://hooktube.com/watch?v=hgN8pCMLI2U I wonder why they chose to not implement them? Seems like a very strange thing for OpenBSD to not do.

>>7604 It might be better to just fix chroot because it's already in but this might just be one of those things where the OpenBSD "stop complaining and do something about it" thing comes to play, and it's just too large a task to get done in a hackathon, or too low priority.

>>7604 I just re-watched that presentation I wasn't trying to be sarcastic. Jails have problems but they are still so much better than chroot.

>>7604 >I wonder why they chose to not implement them? Seems like a very strange thing for OpenBSD to not do. Not strange. The focus of OpenBSD is not actually security it's correctness. So they would rather not have a feature at all instead of implement it badly.

Where can I find a complete list of packages / binaries that are included in the OpenBSD base install?

>>7613 I can't seem to find a list anywhere.

>>7600 >There is zero horizontal security. If you run firefox and ssh from the same user account, you can't stop firefox from reading your ssh keys and shipping them off over the network. Everything is either fully trusted or you don't run it. running web browsers on a different user account is generally encouraged >>7613 just look under the bin folders in the source tree? that'll give you an idea. third party packages are also listed on the release pages

A bit off topic, but I've just been trying to install OpenBSD on my Librebooted x200 and its not going great. I think its mostly libreboot's fault, because the install worked, but it can't boot into it. When it turns on its just a load of errors and it can't open any partition. Not even the boot commands provided by libreboot or OpenBSD have worked. If you are planning to install OpenBSD on your x200, here is what I have learned. >even if you have an intel processor, use amd64 version. I have no idea why the i386 version doesn't work, but that might just be because I'm an idiot. I'm sure someone will let me know. >install62.fs is the option to choose >if you are on GNU/Linux, checking the signatures is done with the package 'signify' but on my distro for some reason, something else has that title. You need to get 'signify-openbsd' Just check your package manager before you install anything >if you get it to load then congrats. hit (i) and when you get to the part where it asks to download the files, you have to tell it's getting them from the storage device, not the internet. Also, it will tell you it can't check their signatures, that's fine with install62.fs That's what I can remember at the moment. I'm waiting for my hard drive to finish cleaning before I try again. I also think you should wipe your drive before you start installing OpenBSD, that might have been my problem. Tomorrow I'll try again using the method described by the libreboot site, if it doesn't work I'm going to try to do it the way you normally would. Just writing an ISO image to a usb and crossing my fingers that I don't have to install a different BIOS. If anyone here has installed OpenBSD on a Librebooted system, let me know if you have had any of these problems, and how you might have solved them.

>>7900 cont. The exact problem is after the install and reboot. I get into the BIOS command line and type: >kopenbsd -r sd0a (achi0,gpt4)/bsd and in response I get: >error: disk 'achi0,gpt4' not found I booted into a linux terminal and lsblk showed that sda was correct and the only two partitions were sda2 and sda4 so I tried all three and nothing worked, same error every time. I would really like an explanation as to why this isn't working

>>7900 >even if you have an intel processor, use amd64 version. >I have no idea why the i386 version doesn't work, but that might just be because I'm an idiot. I'm sure someone will let me know. AMD64(x86-64) and i386 refer to instruction sets/processor architectures and has nothing to do with the brand. Back when 64bit was new you had the IA-64 spec by Intel/HP and the AMD64 by AMD, IA-64 was first with Intel's Itanium processors, AMD64 came along a few years later and AMD put out the Opteron processors. AMD quickly got taken up by the enterprise servers due to the easier upgrade from x86(i386) and Intel saw the change coming and released the Xeon series of processors following the AMD64 spec. AMD64 has become the standard for most things and chances are if you have a consumer grade desktop or laptop with a 64bit processor it follows the AMD spec, the exception being chromebooks and other newer cloud based computers which often use ARMv7 spec and the handful of Intel IA-64 Itanium based computers. i386(x86) refers to IA-32, Intels 32bit spec for their 80386 processors which came out back in the mid 80s and was followed by many processors including AMDs 32bit offerings. Motorola's 68000 series was the main competition for it back then but Apple had the same issues back then as it does today and it never gained much of the market, just like the PPC and G3/G4 processors.