有道理, 现在就剩怎么限制了 (

我觉得限制局域网的话 mdns 一起被限制应该是预期的？

总感觉已经超出flatpak的职责范围了

对

mdns 吗

还有 Bounjour 这类服务怎么办)

怎么越来越重了啊

嗯……确实。这个我觉得也不难，给每个应用程序一个 dns proxy，然后在沙盒里 bind 进一个 resolv.conf 和 nsswitch.conf

至少不能对程序声称的功能做限制

也许之后这一点会改变

因为我不信任在相同硬件上隔离可访问资源的技术

其实除了能不能直接与内核对话之外没什么区别

因为用户的 DNS server 可能在任何地方, 不允许就炸了)

* 是的，我目前的方法是隔离设备以及VM

网页直接在浏览器上运行，浏览器能做的控制更多一些吧。但是把预计自己在机器上运行的程序弄到沙盒里面那就不一样了

为什么要涉及 dns（

> <@kimiblock:kimiblock.top> 某些闭源软件当然想方设法阻挠你使用沙盒 是的，我目前的方法是隔离设备

有什么可靠的方法 parse DNS server 吗 (

我觉得限制 localhost 和局域网应该对绝大部分程序来说不会 break

某些闭源软件当然想方设法阻挠你使用沙盒

感觉确实有必要实现类似的功能，但能不能不break现有的东西呢

就像之前的 polyfill，不是网站自己想爆的，供应链攻击我有什么办法.jpg

那很多时候你没有足够的精力去判断一个网站到底是否恶意

好吧，我不了解namespace能够提供的防护

我怎么可能审查网站的每个 js (

* 所以浏览器也会使用 namespace 作为纵深防御

使用浏览器也会使用 namespace 作为纵深防御

应用沙盒可不需要考虑这个攻击面特大的玩意

> <@nyaacinth:mozilla.org> 一些风险网站你最好别点进去 .

* 而且像浏览器这种为了性能考虑，普遍使用了 JIT，而怎么样保证 JIT 没有洞洞那就更是

而且像浏览器这种为了性能考虑，普遍使用了 JIT，而怎么样保证 JIT 没有洞洞那就更是重灾区

请预先审查自己访问的内容，一些明确高危的内容不要访问

> <@telegram_7516932753:nichi.co> 虽然但是浏览器的沙盒也不是固若金汤啊 确实

是程序就会有漏洞, 这是完全无法避免的

过去一年不都有 N 个补丁和安全沙盒穿了有关系

是这样的

这就是个安全边界的问题，应用程序沙箱必然要信任内核作为安全边界

虽然但是浏览器的沙盒也不是固若金汤啊

为什么不可能，因为应用程序能调用内核？

我是在VM运行的，也有逃逸可能

难道要给每个闭源程序都分配一台机器运行吗, 这显然是不合理的

你在bare metal上不可能实现浏览器的完全沙箱

只是具体的攻击面大小不同

我已经说过了

因为本质上是一样的

还是那句话，如果你在运行每一条 js 之前也防范那我不说什么

防范应该在运行前

我觉得没必要过于防范自己运行的程序……

我觉得没必要过于防范自己运行的程序……

* 自己实现应该是可行的，xwayland-run 做的事情不多

应该是可行的，xwayland-run 做的事情不多

应用程序沙箱也可以，依靠 namespace 来保证，最大可以把程序限制到只能与内核对话

而且我有自己的进程管理模型, xwayland-run 的不适合

spawn 外部程序不可控且慢

js 被设计在运行浏览器上，native 不一样，不是被设计运行在这些native沙盒的，所以浏览器能做更好的安全机制

话说，Wayland上有啥好用的极简的混成器推荐下吗？（Sway除外，这玩意对Nvidia没有很好的支持）

* JavaScript不具备取用提供浏览器暴露的API之外内容的能力，这一点由JavaScript实现自身来保证

JavaScript不具备取用提供浏览器暴露的API之外内容的能力，这一点由JavaScript自身来保证

不是很想引入新包

为什么要自己实现呢

只能说 native 应用程序攻击面肯定大了很多，因为能直接调用内核，不做限制的话还可以 IPC。但做好限制的话还是能好不少的

我在想能不能直接自己实现一个 xwayland-run 用

> <@telegram_824372155:nichi.co> js 同理 首先：不同

二进制程序面对的是bare metal

js 同理

> <@telegram_824372155:nichi.co> 应用程序沙箱就不能有吗（ 因为完全有效的应用程序沙箱不存在

而且怎么让用户能够方便地授权, 并且阻止打包者乱搞

一些风险网站你最好别点进去

应用程序沙箱就不能有吗（

这个比较合理, 但是想要避免 break stuff 会比较麻烦

> <@telegram_824372155:nichi.co> 如果你的浏览器禁用 js 的话，那我认同这句话 浏览器具有合理的安全模型，我在编写JavaScript程序时已经撞过无数回了

如果你的浏览器禁用 js 的话，那我认同这句话

我觉得通常也没必要分那么细，大多数需求应该就限制一下 localhost 和局域网就足够了

* 如果已知一个软件行为不良但又必须运行，最应该做的是放进VM或物理隔离设备

如果已知一个软件行为不良，最应该做的是放进VM或物理隔离设备

现在做得不好不代表就该什么都不做了

我的观点还是用户应当自行筛选具体运行的程序，你不可能指望操作系统在没有巨大overhead的情况下有效防护恶意软件

（耸肩）

打包者不可能找到所有要访问的东西, 最后大家又是 allow all

per-app firewall 最大的问题就是我不知道闭源软件想访问什么, 并且 DNS 解析会变

无论如何flatpak是一种跨发行版发行方式，而不是个sandboxie类似物

* 就先不说中国这边，欧洲的eduVPN（教育网）强制TUN模式的

flatpak有N种方法逃逸沙箱，flathub里一部分开发工具甚至默认逃逸

如果你觉得这个软件都这么malware了，一个很容易逃逸的沙箱（flatpak）显然不是该放它的正确位置

我还是觉得这个需求比较诡异

其它本地网络 block 掉

所以理论上可以 parse resolv.conf 把 DNS 服务器 allowlist 了

怎么保证桥到正确的设备

就先不说中国这边，欧洲的eduVPN强制TUN模式的

block 本地设备还是可以考虑的... 但是怎么做到不 break 东西

在宿主机搞复杂网络配置的情况下这个方案能不能无感完成自身网络配置是个问题

> <@kimiblock:kimiblock.top> 手机上一直是 global allow/deny 也没见有啥问题) 确实

手机上一直是 global allow/deny 也没见有啥问题)

我觉得它会遇到各VM网络桥类似的问题

而且

出现异常很可能无法轻易完成清理

> <@kimiblock:kimiblock.top> 我觉得作者的方案有点过于重且 fragile 了 我也觉得

我觉得作者的方案有点过于重且 fragile 了

限制网络访问吧，目前 netns 里如果不用用户空间网络栈，就没法在非特权的情况下访问网络

所以桌面端防火墙的主要目的是什么呢