4 ms·

Check out OpenBSD's pledge(2): https://man.openbsd.org/pledge.2 https://man.openbsd.org/pledge.2 It does exactly that (although on a per-process basis). I don

Check out OpenBSD's pledge(2): https://man.openbsd.org/pledge.2 https://man.openbsd.org/pledge.2 It does exactly that (although on a per-process basis). I don't think this kind of permission system can be retrofitted into an existing language without direct OS support, and probably not at the library level (you'd need something like per-page permissions which would get hairy real fast).

musicale 4y ago
I like this. I'd try to keep the permission sets as small, limited, and simple as possible though.
- rollcat 4y ago
  > I'd try to keep the permission sets as small and simple as possible though. You've described OpenBSD in general. I recommend a deeper dive - it's fantastically refreshing, how simple yet functional an OS can be.
  - paulmd 4y ago
    Same for FreeBSD. Incredibly code-stable and well-documented by Linux standards. I often use the FreeBSD Handbook as an example of first-party documentation done right, and that's only possible because of deliberately limited "churn for churn's sake". The kinds of regular code rot and attrition that Linux suffers just does not take place on BSD systems because if you contribute something new you're expected to make your thing mesh with the ecosystem, they don't tolerate the "I'm gonna churn everyone's environments because my version is 10% better than the existing one" that tends to take place on Linux. As an example, the amount of init systems that Ubuntu has gone through over the last 20 years is completely insane by BSD standards. They've gone from sysvinit to upstart to systemd. You don't have people ripping out the graphics and audio subsystems and doing total rewrites, either. It's nuts that a lot of Linux people don't even realize that it doesn't have to be that way - that's not "just how maintenance is supposed to work", that's a bunch of incredibly bad behavior on the parts of distros and Poettering specifically that has become highly normalized and overlooked. Maintenance shouldn't be breaking things like that. "we never break userland" doesn't have to be a suicide pact either - BSD has actually maintained a much more stable ABI than the linux kernel without crystallizing a bunch of shitty bug-compatibility stuff like Linux is doing either. It's all insanely stable and competent and professional by linux standards. If I was developing a product for true long-term support, with the minimum possible engineering effort devoted to fighting churn, BSD would be at the top of the list.
    - CoolCold 4y ago
      And with all that beauty, FreeBSD is not something I would [nowdays] look into as base OS for hosting my services and products. It means something, probably something about humans.
      - rollcat 4y ago
        Netflix uses FreeBSD for their CDN/edge caches - it was consistently more performant both in benchmarks and with real-world workloads.
        CoolCold 4y ago
        Yeah, that's quite interesting reading from them, some sort of specialized appliance really. I'm and the average Joe around me, totally far from Netflix's task of packing bytes from disk to network. Simple 2vCPU VPS serving 4GBit without being saturated on system resource level is quite often much more than enough. Extra note - it's not even using kTLS. Moreover, even for Netflix, noting they know FreeBSD in and out, do you think/have info on using FreeBSD as base OS beyond distribution level - running applications/services in particular? I've quickly checked on their repos like https://github.com/Netflix/conductor https://github.com/Netflix/conductor and it smells like they use containers/Docker, which doesn't work on FreeBSD => I'm in very much doubts it's OS of choice for them.
    - washadjeffmad 4y ago
      What attracted me to Linux so long ago is what ultimately drove me away. I now apply it only as needed because it's no longer simple ("stable" over the timescales I'm interested in) as a project, and it's not moving towards any type of consistency. If you read "rolling stones gather no moss" to mean "keep moving or risk becoming obsolete", choose Linux. If you understand it as "change for change's sake prevents the achievement of mastery", go with a BSD.
  - bumblebritches5 4y ago
dilawar 4y ago
I think @jart has been porting it to Linux https://justine.lol/pledge/ https://justine.lol/pledge/ .
- jart 4y ago
  Indeed! If your dependencies are able to be command line programs that are shell scripted together, then you can in fact have an access policy on a per-dependency basis, using the pledge.com program linked on my website. So shell scripters rejoice. But it gets better. If you build Python in the Cosmopolitan Libc repository: git clone https://github.com/jart/cosmopolitan cd cosmopolitan build/bootstrap/make.com -j8 o//third_party/python/python.com Then you can use cosmo.pledge() directly from Python. $ o//third_party/python/python.com Python 3.6.14+ (Actually Portable Python) [GCC 9.2.0] on cosmo Type "help", "copyright", "credits" or "license" for more information. >>: import cosmo, socket >>: cosmo.pledge('stdio rpath wpath tty', None) >>: print('hi') hi >>: socket.socket() Traceback (most recent call last): File "<stdin>", line 1, in <module> File "/zip/.python/socket.py", line 144, in __init__ _socket.socket.__init__(self, family, type, proto, fileno) PermissionError: [Errno 1] EPERM/1/Operation not permitted Since we didn't put "inet" in the pledge, you can now be certain your PyPi deps aren't spying on you or uploading your bitcoin wallet to the cloud. You can even use os.fork() to rapidly put each dependency in its own process, then call cosmo.pledge() afterwards to grant each component of your app its own maximally restrictive policy. Cosmopolitan Python also ports OpenBSD's unveil() system call to Linux too. For example, to disallow all file system access, just call cosmo.unveil(None, None). You need a very recent version of Linux though. For instance, I use unveil() in production on GCE but I had to apt install linux-image-5.18.0-0.deb11.4-cloud-amd64 in order for Landlock LSM to be available to use unveil().
  - gjadi 4y ago
    I thought the thread model of pledge/unveil was to restrict a program that you are writing, but that you couldn't wrap around other program in a safe way. That is, you can protect your own program from doing network stuff because of incorrect input, but you can't use it to sandbox another program. See this thread: https://marc.info/?t=162367803300003&r=1&w=2 https://marc.info/?t=162367803300003&r=1&w=2 and this mail about sandboxing: https://marc.info/?l=openbsd-tech&m=162367954705721&w=2 https://marc.info/?l=openbsd-tech&m=162367954705721&w=2
mrlemke 4y ago
I thought of OpenBSD too since it includes Perl modules for OpenBSD::Pledge and OpenBSD::Unveil. Now I'm wondering if I can get something to work where these are used before importing CPAN modules to reduce the damage of potentially hostile modules.

musicale 4y ago

I like this. I'd try to keep the permission sets as small, limited, and simple as possible though.

rollcat 4y ago
> I'd try to keep the permission sets as small and simple as possible though. You've described OpenBSD in general. I recommend a deeper dive - it's fantastically refreshing, how simple yet functional an OS can be.
- paulmd 4y ago
  Same for FreeBSD. Incredibly code-stable and well-documented by Linux standards. I often use the FreeBSD Handbook as an example of first-party documentation done right, and that's only possible because of deliberately limited "churn for churn's sake". The kinds of regular code rot and attrition that Linux suffers just does not take place on BSD systems because if you contribute something new you're expected to make your thing mesh with the ecosystem, they don't tolerate the "I'm gonna churn everyone's environments because my version is 10% better than the existing one" that tends to take place on Linux. As an example, the amount of init systems that Ubuntu has gone through over the last 20 years is completely insane by BSD standards. They've gone from sysvinit to upstart to systemd. You don't have people ripping out the graphics and audio subsystems and doing total rewrites, either. It's nuts that a lot of Linux people don't even realize that it doesn't have to be that way - that's not "just how maintenance is supposed to work", that's a bunch of incredibly bad behavior on the parts of distros and Poettering specifically that has become highly normalized and overlooked. Maintenance shouldn't be breaking things like that. "we never break userland" doesn't have to be a suicide pact either - BSD has actually maintained a much more stable ABI than the linux kernel without crystallizing a bunch of shitty bug-compatibility stuff like Linux is doing either. It's all insanely stable and competent and professional by linux standards. If I was developing a product for true long-term support, with the minimum possible engineering effort devoted to fighting churn, BSD would be at the top of the list.
  - CoolCold 4y ago
    And with all that beauty, FreeBSD is not something I would [nowdays] look into as base OS for hosting my services and products. It means something, probably something about humans.
    - rollcat 4y ago
      Netflix uses FreeBSD for their CDN/edge caches - it was consistently more performant both in benchmarks and with real-world workloads.
      - CoolCold 4y ago
        Yeah, that's quite interesting reading from them, some sort of specialized appliance really. I'm and the average Joe around me, totally far from Netflix's task of packing bytes from disk to network. Simple 2vCPU VPS serving 4GBit without being saturated on system resource level is quite often much more than enough. Extra note - it's not even using kTLS. Moreover, even for Netflix, noting they know FreeBSD in and out, do you think/have info on using FreeBSD as base OS beyond distribution level - running applications/services in particular? I've quickly checked on their repos like https://github.com/Netflix/conductor https://github.com/Netflix/conductor and it smells like they use containers/Docker, which doesn't work on FreeBSD => I'm in very much doubts it's OS of choice for them.
  - washadjeffmad 4y ago
    What attracted me to Linux so long ago is what ultimately drove me away. I now apply it only as needed because it's no longer simple ("stable" over the timescales I'm interested in) as a project, and it's not moving towards any type of consistency. If you read "rolling stones gather no moss" to mean "keep moving or risk becoming obsolete", choose Linux. If you understand it as "change for change's sake prevents the achievement of mastery", go with a BSD.
- bumblebritches5 4y ago

dilawar 4y ago

I think @jart has been porting it to Linux https://justine.lol/pledge/ https://justine.lol/pledge/ .

jart 4y ago
Indeed! If your dependencies are able to be command line programs that are shell scripted together, then you can in fact have an access policy on a per-dependency basis, using the pledge.com program linked on my website. So shell scripters rejoice. But it gets better. If you build Python in the Cosmopolitan Libc repository: git clone https://github.com/jart/cosmopolitan cd cosmopolitan build/bootstrap/make.com -j8 o//third_party/python/python.com Then you can use cosmo.pledge() directly from Python. $ o//third_party/python/python.com Python 3.6.14+ (Actually Portable Python) [GCC 9.2.0] on cosmo Type "help", "copyright", "credits" or "license" for more information. >>: import cosmo, socket >>: cosmo.pledge('stdio rpath wpath tty', None) >>: print('hi') hi >>: socket.socket() Traceback (most recent call last): File "<stdin>", line 1, in <module> File "/zip/.python/socket.py", line 144, in __init__ _socket.socket.__init__(self, family, type, proto, fileno) PermissionError: [Errno 1] EPERM/1/Operation not permitted Since we didn't put "inet" in the pledge, you can now be certain your PyPi deps aren't spying on you or uploading your bitcoin wallet to the cloud. You can even use os.fork() to rapidly put each dependency in its own process, then call cosmo.pledge() afterwards to grant each component of your app its own maximally restrictive policy. Cosmopolitan Python also ports OpenBSD's unveil() system call to Linux too. For example, to disallow all file system access, just call cosmo.unveil(None, None). You need a very recent version of Linux though. For instance, I use unveil() in production on GCE but I had to apt install linux-image-5.18.0-0.deb11.4-cloud-amd64 in order for Landlock LSM to be available to use unveil().
- gjadi 4y ago
  I thought the thread model of pledge/unveil was to restrict a program that you are writing, but that you couldn't wrap around other program in a safe way. That is, you can protect your own program from doing network stuff because of incorrect input, but you can't use it to sandbox another program. See this thread: https://marc.info/?t=162367803300003&r=1&w=2 https://marc.info/?t=162367803300003&r=1&w=2 and this mail about sandboxing: https://marc.info/?l=openbsd-tech&m=162367954705721&w=2 https://marc.info/?l=openbsd-tech&m=162367954705721&w=2

mrlemke 4y ago

I thought of OpenBSD too since it includes Perl modules for OpenBSD::Pledge and OpenBSD::Unveil. Now I'm wondering if I can get something to work where these are used before importing CPAN modules to reduce the damage of potentially hostile modules.