4 ms·

Wait, OpenBSD didn't have MAP_NOCORE? FreeBSD added that in February 2000... I always assumed that the other BSDs had long since picked it up. Huh.

wahern 7y ago
Pretty sure they've deliberately kept it out on principle: better to encrypt swap, ensure permissions on core files are strict, etc, rather than hope all applications correctly set MAP_NOCORE on every bit of sensitive data. Sounds like it just became too inconvenient to avoid, though.
- tedunangst 7y ago
  Deliberate makes it sound like we wanted secrets to appear in the core files. I don't think that's the case, but otherwise yes, there's been a certain amount of care to making core files secure.
  - throwaway2048 7y ago
    Why even bother with core files if you aren't a developer? they are completely useless for an average user and are really nothing but a risk.
    - asveikau 7y ago
      I feel like this kind of culture may be dying in most places. But it used to be a common thing that you could pass a core file around to someone knowledgeable who knew what to do with it. In a workplace or university, maybe someone on staff who is technical. In a piece of software, either open source or commercial, maybe its developer. Obviously there is trust implicit in that, because core files contain your data. On Windows, their equivalent of core files gets sent to Microsoft and they run analysis on them to get most common stack traces for crashing bugs. If you're opted in.
    - SmellyGeekBoy 7y ago
      To be fair, I'm not sure OpenBSD is targeted at the "average user".
    - bluGill 7y ago
      Why doesn't the system automatically pass core files to someone who knows how to deal with them. I work on an embedded system and our system to get core files back from the users has meant a lot of crashes go from "no idea what happened, closed" to "found the bug and fixed it". Of course there are security implications. Developers are not allowed to see core files from real customers unless the customer agrees. However our test department and our beta tests agree to this. I don't think anyone has ever looked into a core file to see sensitive data not related to the crash but the possibility exists.
- Someone 7y ago
  ”better to encrypt swap, ensure permissions on core files are strict” I don’t think that’s entirely true. A risk this mitigates against is that system administrators read a user’s most sensitive data when they help them debug a crash. Encrypting the disk won’t protect against that. Making the core dump owned by the user running the executable won’t, either, because a) the user will have to make the file readable by the system administrators to get help fixing the crash problem, and b) one can assume the system administrators have root privileges, anyways. On the other hand, a) programs can’t know what a user’s most sensitive data is (for example, they might be writing in their diary), and b) why would users trust a program to protect their most sensitive data in that way, given that it doesn’t even manage to “not crash“?
tedunangst 7y ago
Do you know of anything using it? I haven't seen it come up before.
- notaplumber 7y ago
  Survey says, in the past ~20 years.. https://github.com/freebsd/freebsd/search?q=MAP_NOCORE&unscoped_q=MAP_NOCORE https://github.com/freebsd/freebsd/search?q=MAP_NOCORE&unsco... Pretty much bupkis. But still more than Capsicum!
- cperciva 7y ago
  There's a few utilities in the FreeBSD base system which use MAP_NOCORE -- I think mostly as a "this isn't useful so don't waste time dumping it" flag: mkimg, sort, grep. The libsodium we have imported into sys/contrib also mention it, but I don't know if those parts of libsodium are ever used by the FreeBSD userland. Grepping the ports distfiles on my laptop, I see MAP_NOCORE mentioned in Cython, rust, qemu, firefox, and thunderbird; again, no idea how it's being used in those. In the interest of compatibility, can I suggest #define MAP_NOCORE MAP_CONCEAL for now, and in the future if MAP_CONCEAL adds new functionality define it as MAP_NOCORE|MAP_CONCEAL_EXTRA? Since you have the capability to exclude regions from core dumps, you might as well expose it to programs which are aware of MAP_NOCORE. PS. Linux has MADV_DONTDUMP and FreeBSD has MADV_NOCORE; I'd suggest handling those as well if you don't already do so.
  - tedunangst 7y ago
    I don't think the intention was to be incompatible. I'll see about adding aliases.
    - cperciva 7y ago
      Thanks!
    - hedora 7y ago
      Clarification in the documentation about what happens with swap files would be nice, especially as aliases are added. “Conceal” (but not the manpage) suggests it won’t ever be written to swap, but “nocore” as a performance optimization suggests paging to swap is fine. If dirty concealed pages can’t be swapped, then it starts to look like mlock(), which requires escalated privileges on linux, at least... (Though, paging dirty mmapped pages to swap is kind of confusing in the first place.)

wahern 7y ago

Pretty sure they've deliberately kept it out on principle: better to encrypt swap, ensure permissions on core files are strict, etc, rather than hope all applications correctly set MAP_NOCORE on every bit of sensitive data. Sounds like it just became too inconvenient to avoid, though.

tedunangst 7y ago
Deliberate makes it sound like we wanted secrets to appear in the core files. I don't think that's the case, but otherwise yes, there's been a certain amount of care to making core files secure.
- throwaway2048 7y ago
  Why even bother with core files if you aren't a developer? they are completely useless for an average user and are really nothing but a risk.
  - asveikau 7y ago
    I feel like this kind of culture may be dying in most places. But it used to be a common thing that you could pass a core file around to someone knowledgeable who knew what to do with it. In a workplace or university, maybe someone on staff who is technical. In a piece of software, either open source or commercial, maybe its developer. Obviously there is trust implicit in that, because core files contain your data. On Windows, their equivalent of core files gets sent to Microsoft and they run analysis on them to get most common stack traces for crashing bugs. If you're opted in.
  - SmellyGeekBoy 7y ago
    To be fair, I'm not sure OpenBSD is targeted at the "average user".
  - bluGill 7y ago
    Why doesn't the system automatically pass core files to someone who knows how to deal with them. I work on an embedded system and our system to get core files back from the users has meant a lot of crashes go from "no idea what happened, closed" to "found the bug and fixed it". Of course there are security implications. Developers are not allowed to see core files from real customers unless the customer agrees. However our test department and our beta tests agree to this. I don't think anyone has ever looked into a core file to see sensitive data not related to the crash but the possibility exists.
Someone 7y ago
”better to encrypt swap, ensure permissions on core files are strict” I don’t think that’s entirely true. A risk this mitigates against is that system administrators read a user’s most sensitive data when they help them debug a crash. Encrypting the disk won’t protect against that. Making the core dump owned by the user running the executable won’t, either, because a) the user will have to make the file readable by the system administrators to get help fixing the crash problem, and b) one can assume the system administrators have root privileges, anyways. On the other hand, a) programs can’t know what a user’s most sensitive data is (for example, they might be writing in their diary), and b) why would users trust a program to protect their most sensitive data in that way, given that it doesn’t even manage to “not crash“?

tedunangst 7y ago

Do you know of anything using it? I haven't seen it come up before.

notaplumber 7y ago
Survey says, in the past ~20 years.. https://github.com/freebsd/freebsd/search?q=MAP_NOCORE&unscoped_q=MAP_NOCORE https://github.com/freebsd/freebsd/search?q=MAP_NOCORE&unsco... Pretty much bupkis. But still more than Capsicum!
cperciva 7y ago
There's a few utilities in the FreeBSD base system which use MAP_NOCORE -- I think mostly as a "this isn't useful so don't waste time dumping it" flag: mkimg, sort, grep. The libsodium we have imported into sys/contrib also mention it, but I don't know if those parts of libsodium are ever used by the FreeBSD userland. Grepping the ports distfiles on my laptop, I see MAP_NOCORE mentioned in Cython, rust, qemu, firefox, and thunderbird; again, no idea how it's being used in those. In the interest of compatibility, can I suggest #define MAP_NOCORE MAP_CONCEAL for now, and in the future if MAP_CONCEAL adds new functionality define it as MAP_NOCORE|MAP_CONCEAL_EXTRA? Since you have the capability to exclude regions from core dumps, you might as well expose it to programs which are aware of MAP_NOCORE. PS. Linux has MADV_DONTDUMP and FreeBSD has MADV_NOCORE; I'd suggest handling those as well if you don't already do so.
- tedunangst 7y ago
  I don't think the intention was to be incompatible. I'll see about adding aliases.
  - cperciva 7y ago
    Thanks!
  - hedora 7y ago
    Clarification in the documentation about what happens with swap files would be nice, especially as aliases are added. “Conceal” (but not the manpage) suggests it won’t ever be written to swap, but “nocore” as a performance optimization suggests paging to swap is fine. If dirty concealed pages can’t be swapped, then it starts to look like mlock(), which requires escalated privileges on linux, at least... (Though, paging dirty mmapped pages to swap is kind of confusing in the first place.)