6 ms·

I would love to see all the other operating systems adopt pledge(), but as is often the case with OpenBSD's security mitigations, it will be years before we see

I would love to see all the other operating systems adopt pledge(), but as is often the case with OpenBSD's security mitigations, it will be years before we see it happen (if at all).

LukeShu 11y ago
This is kind-of a different case than most mitigations, though. It's right now only possible because OpenBSD takes a whole-system approach to development; how the different syscall groups work can change, and right now only follows "this seems like it aligns with how we usually do things in OpenBSD." But yes, I would like to see a similar mechanism appear in other operating systems.
- binarycrusader 11y ago
  OpenBSD is not unique here; Solaris has a "whole-system approach" to development as well, and has had the ability for programs and admins to easily do privilege drop or provide privilege separation for many years now. Not only that, Solaris allows you to wrap programs without any source modifications easily using ppriv to drop or add privileges as required. Almost every slide in the presentation that talks about how you would use the proposed pledge() interface applies to Solaris' privileges model as well. Some relevant examples: http://www.kernelthread.com/publications/security/solaris.html http://www.kernelthread.com/publications/security/solaris.ht... http://docs.oracle.com/cd/E23823_01/html/816-4863/ch3priv-25082.html#eyals http://docs.oracle.com/cd/E23823_01/html/816-4863/ch3priv-25... Solaris' role-based access control and advanced privileges model even lets you implement things like only allowing someone to become 'root' if both them and another person logs in at the same time. Think of the "two-keys required to unlock this door" sort of approach to security: https://blogs.oracle.com/gbrunett/entry/enforcing_a_two_man_rule https://blogs.oracle.com/gbrunett/entry/enforcing_a_two_man_...
  - LukeShu 11y ago
    My point about OpenBSD having a "whole-system approach" was that the interface isn't necessarily general (yet); it just needs to meet the needs of the OpenBSD team as they exist today. When they realize it has a limitation, they can change it, no fuss, because they can commit to the whole system. That said, Solaris' facilities seem useful, but from the documentation you linked, seems much more complicated than pledge(). They look similar conceptually, but Solaris' seems to be much more complicated to actually use.
    - binarycrusader 11y ago
      The examples provided are some of the more complex cases that let you do advanced things. You can shrink the amount of code required if you limit it to more simple cases as those shown in the slides. For example, as derived from the OpenBSD presentation: if (pledge("stdio fattr", NULL) == -1): err(1, "pledge"); A similar (not completely equivalent, since OpenBSD chose some "interesting" definitions for their privileges, and is admittedly untested) example for Solaris might be: priv_set_t *tmp = priv_str_to_set( "PRIV_FILE_READ PRIV_FILE_WRITE PRIV_FILE_CHOWN_SELF", " ", NULL); /* Assert required privileges. */ if (setppriv(PRIV_ON, PRIV_PERMITTED, tmp) == -1) err(1, "setppriv permitted"); if (setppriv(PRIV_ON, PRIV_EFFECTIVE, tmp) == -1) err(1, "setppriv effective"); priv_inverse(tmp); /* Drop all privileges not required. */ (void) setppriv(PRIV_OFF, PRIV_PERMITTED, tmp); The big difference, I think, between the Solaris interfaces and the OpenBSD ones are that Solaris allows the process to temporarily drop privileges and then add them back, or permanently drop them. From the proposed OpenBSD interfaces, it looks they only allow the permanent drop model. There are a few convenience wrappers that might simplify the above further, but the real point is not to compare efficiency of interfaces, but capability. Also, Solaris offers the ability to restrict privileges of programs without source code modification (imagine a program you don't quite trust and don't have the source code to). I didn't see that in the OpenBSD presentation. In their defense, they're also clearly still working on these interfaces, so there can't yet be a fair comparison. Solaris has had privilege interfaces for over a decade, so the model presented is a bit more mature obviously. The only thing I'd mention is that Solaris tries to provide a default set of privileges that represent things closer to administrative boundaries, rather then implementation-specific ones, as implementation can change, but the basic high-level operations do not. For example, Solaris has a file read/write privilege, but doesn't bother letting you restrict the ability to set file timestamps separately because that doesn't seem like a useful thing to do. It does however, provide separate privilege(s) for manipulating ownership of files, since that's clearly a different category of operations. OpenBSD currently seems to be focused on the implementation instead of the administrative-level operations being performed.
pkaye 11y ago
Why do you feel this way when even OpenBSD hasn't fully worked out all the details (see the slides) and proven it will work well in practice.
- sarciszewski 11y ago
  Because I think whitelisting the syscalls at init and only being able to drop syscalls is a great idea.
- deleted 11y ago
  [deleted]

I would love to see all the other operating systems adopt pledge(), but as is often the case with OpenBSD's security mitigations, it will be years before we see it happen (if at all).

LukeShu 11y ago

This is kind-of a different case than most mitigations, though. It's right now only possible because OpenBSD takes a whole-system approach to development; how the different syscall groups work can change, and right now only follows "this seems like it aligns with how we usually do things in OpenBSD." But yes, I would like to see a similar mechanism appear in other operating systems.

binarycrusader 11y ago
OpenBSD is not unique here; Solaris has a "whole-system approach" to development as well, and has had the ability for programs and admins to easily do privilege drop or provide privilege separation for many years now. Not only that, Solaris allows you to wrap programs without any source modifications easily using ppriv to drop or add privileges as required. Almost every slide in the presentation that talks about how you would use the proposed pledge() interface applies to Solaris' privileges model as well. Some relevant examples: http://www.kernelthread.com/publications/security/solaris.html http://www.kernelthread.com/publications/security/solaris.ht... http://docs.oracle.com/cd/E23823_01/html/816-4863/ch3priv-25082.html#eyals http://docs.oracle.com/cd/E23823_01/html/816-4863/ch3priv-25... Solaris' role-based access control and advanced privileges model even lets you implement things like only allowing someone to become 'root' if both them and another person logs in at the same time. Think of the "two-keys required to unlock this door" sort of approach to security: https://blogs.oracle.com/gbrunett/entry/enforcing_a_two_man_rule https://blogs.oracle.com/gbrunett/entry/enforcing_a_two_man_...
- LukeShu 11y ago
  My point about OpenBSD having a "whole-system approach" was that the interface isn't necessarily general (yet); it just needs to meet the needs of the OpenBSD team as they exist today. When they realize it has a limitation, they can change it, no fuss, because they can commit to the whole system. That said, Solaris' facilities seem useful, but from the documentation you linked, seems much more complicated than pledge(). They look similar conceptually, but Solaris' seems to be much more complicated to actually use.
  - binarycrusader 11y ago
    The examples provided are some of the more complex cases that let you do advanced things. You can shrink the amount of code required if you limit it to more simple cases as those shown in the slides. For example, as derived from the OpenBSD presentation: if (pledge("stdio fattr", NULL) == -1): err(1, "pledge"); A similar (not completely equivalent, since OpenBSD chose some "interesting" definitions for their privileges, and is admittedly untested) example for Solaris might be: priv_set_t *tmp = priv_str_to_set( "PRIV_FILE_READ PRIV_FILE_WRITE PRIV_FILE_CHOWN_SELF", " ", NULL); /* Assert required privileges. */ if (setppriv(PRIV_ON, PRIV_PERMITTED, tmp) == -1) err(1, "setppriv permitted"); if (setppriv(PRIV_ON, PRIV_EFFECTIVE, tmp) == -1) err(1, "setppriv effective"); priv_inverse(tmp); /* Drop all privileges not required. */ (void) setppriv(PRIV_OFF, PRIV_PERMITTED, tmp); The big difference, I think, between the Solaris interfaces and the OpenBSD ones are that Solaris allows the process to temporarily drop privileges and then add them back, or permanently drop them. From the proposed OpenBSD interfaces, it looks they only allow the permanent drop model. There are a few convenience wrappers that might simplify the above further, but the real point is not to compare efficiency of interfaces, but capability. Also, Solaris offers the ability to restrict privileges of programs without source code modification (imagine a program you don't quite trust and don't have the source code to). I didn't see that in the OpenBSD presentation. In their defense, they're also clearly still working on these interfaces, so there can't yet be a fair comparison. Solaris has had privilege interfaces for over a decade, so the model presented is a bit more mature obviously. The only thing I'd mention is that Solaris tries to provide a default set of privileges that represent things closer to administrative boundaries, rather then implementation-specific ones, as implementation can change, but the basic high-level operations do not. For example, Solaris has a file read/write privilege, but doesn't bother letting you restrict the ability to set file timestamps separately because that doesn't seem like a useful thing to do. It does however, provide separate privilege(s) for manipulating ownership of files, since that's clearly a different category of operations. OpenBSD currently seems to be focused on the implementation instead of the administrative-level operations being performed.

pkaye 11y ago

Why do you feel this way when even OpenBSD hasn't fully worked out all the details (see the slides) and proven it will work well in practice.

sarciszewski 11y ago
Because I think whitelisting the syscalls at init and only being able to drop syscalls is a great idea.
deleted 11y ago
[deleted]