寻求 Python 代码管控方案

[scoutteemo]

问题引入

公司需要对代码进行管控，以前的代码都是 C 写的，编译工作在远程的服务器上，用 RDP 远程连接到服务器上进行开发，编译后的固件传下来。
现在引入了 python 语言来做的自动化测试方案，需要运行在 本地的 Linux 系统 上，还要 开放 root 权限 。现在同样需要对 python 的代码进行管控。所以在思考有没有什么方式，可以指定 python 这个程序才可以访问到特定的文件和目录， 其他的进程无法访问 。
代码可以是一个整体的加密文件，运行时解密，但解密后的内容要保证不会被轻易取走。或者通过远程服务器实时下发内容运行。最好是能保留调试功能，可以逐行执行代码什么的。由于程序需要依赖硬件，所以代码只能在本地的 Linux 系统上运行才可以。

想到的可能方案

我们在 Windows 平台的软件有类似的设计，会生成一个虚拟的文件系统，具体方式我也不清楚，然后把实际运行的 exe 文件存放在其中，再运行。
这样的话就需要实现一个FUSE，并且要保证这个文件系统是只有指定的进程才可以访问到的。 可以修改cpython的代码，里面融合类似于encfs这样的 FUSE，读的接口只暴露给 cpython 这个程序。然后再加上网络验证，从服务器上获取代码，运行完之后整个销毁掉。
但是这样的方式工程量比较巨大，还是需要先考虑其他可行方式。

[scoutteemo]

@keakon 没什么问题的呀，多人一起 RDP 连同一台服务器，用 SVN 做代码管理，验证代码只需要编译后的二进制文件

[scoutteemo]

@zeroDev 好的，先去了解一下，多谢啦

[scoutteemo]

@youngce 好像是可以，但是这样也没办法进行调试了，在服务器上是没办法运行测试的

[scoutteemo]

@zjsxwc 意思是在远程服务器上编辑好代码，下载到本地的是混淆后的代码，然后再在本地运行这样吗？

[zjsxwc]

@scoutteemo 对呀，商业化脚本语言代码不都是这么干吗

[scoutteemo]

@zjsxwc 喔喔，才接触 python 还不是很了解。混淆之后的代码逆向起来成本会很高的吗？我知道有商业的代码会用 Cython 编译一次，再用 pyinstaller 打包，这样逆向起来就很麻烦了

[makdon]

把设备和代码都部署在远端呗，然后开放用有限权限的用户帐号登上去操作，那个帐号限定只能执行限定的命令

[scoutteemo]

@makdon 不行的，设备一定要在本地才可以，而且需要系统的 root 权限。我们做的设备是在 pcie 总线上用的，一台服务器就这么些 pcie 通道，因为要控制 pci 的配置空间什么的，所以需要 root 权限

[sampeng]

1.所有人签订保密协议.2，电脑不允许插 u 盘。3，所有内网机器没有外网。
也就是参考华为那套，这样你的代码安全了。

[sampeng]

兄 dei，防君子不防小人。签订协议即可。代码真没那么重要。

[ArJun]

你这是多少个亿的大项目，当年 B 站都没你这样管控代码，你有牛逼的方案别人盗不走的

[DoctorCat]

就是云桌面呗，查查云桌面的安全方案，一般都是限制远程网络、有限程序、单向剪贴板。

[scoutteemo]

@DoctorCat 对，现在我们的方案就是这样，一个带限制功能的 RDP 远程桌面。不能使用剪切板，网络也有限制，编译出来的结果通过一个自己研发的软件，审核之后下传到本地。但是这样的方式在这样一个依赖硬件的 Python 程序环境中用不起来，程序需要访问本地的硬件，服务器上运行是不行的，而且硬件还可能需要频繁更换之类的。

[scoutteemo]

@ArJun 那倒也不是什么大项目，因为现在的代码是有这样的管控限制的，看新的 python 代码能不能也加上一样的限制，如果不行或者太麻烦，那当然也不会强行限制断自己手足

[scoutteemo]

@sampeng 😂这就是从另一个角度解决问题了，看看从技术上有没有什么好解决的办法先，不行也不是非得这样

[neoblackcap]

Python 的源代码混淆约定于没有。C 那些也应该是靠强壳才比较安全
说回 Python 吧，我估计你们现在是实际执行的时候会用到 Python 写的脚本吧。对于这个问题，网易的阴阳师就是一个例子，他们是用 Python 写业务逻辑，然后生成 pyc 字节码文件，部署就只部署字节码文件。关键他们已经魔改过 Python 解析器了，但是一样被人逆向了。
所以我觉得你们如果对代码保密程度很高的，那么你们还是继续上 C 什么的吧。Python 要保密，怕是要大改虚拟机

[scoutteemo]

@neoblackcap 好吧，看来这还真是个棘手的问题。像帖子内容上面提到的修改 python 解释器的方案，应该也能起到一定作用吧

[chiu]

我有一点其他疑问：
>> 在本地机器的 pcie 接口上连接设备...连接的设备也可能会经常更换之类的。所以代码在远程服务器上运行的方案基本上是不行了.
我理解中，PCIE 总线上可以挂接多个设备，真的设备类型很多的话，我觉得 5 台以内的 server 数量应该是足够的。如果都能挂接上独立访问，应该就不会有设备需要经常更换的问题。

[scoutteemo]

@chiu PCIE 的通道是 PCIE 设备独占的，例如一个 16 通道的 PCIE 口，就只能连接 4 个 4 通道的设备，不能无限制地挂接设备。
现在还处于初步开发阶段，有时候会把自己的设备跑死，需要重新上断电，但 pcie 不支持热插拔，这时又只能重启服务器来进行解决，甚至需要短接设备引脚，重新烧录程序这样。
设备还存在寿命的问题，不可能一直插在服务器上就不取下来。
有时单个设备存在问题，我们会有替换法替换其他设备来做交叉验证找问题。设备类型倒是很单一，但我们同一个设备(产品)有很多个实现方案，验证完一个方案会需要更换其他方案验证。
同一个方案我们也会使用多个设备来做验证。最后的部署规模估计会到 100 个设备的样子。
另外 PCIE 口可以连接存储设备，这样可以很容易地把代码拷贝走。禁止 PCIE 口的插拔不太现实，因为替换设备的需求还是存在的。
在后期部署成熟后，这个方法说不定可行。不同的实现方案可以固定对应不同的机器，再加上插拔限制，应该是能实现这个方式

[kaneg]

要保密就不要选 Python 这种解释型的语言。之前看到过类似的，比如加密 php，js，java 等。这些解释型的语言只要你把发布的产品给别人，真要防黑客是不可能的。在上面做的各类混淆，加密都只是增加一点难度，属于掩耳盗铃的做法。你的代码如果价值不大，做这些就是白白浪费人力。如果你的代码价值真的很大，是业内的核心资产，你用力保护，人家也会不遗余力的破解，而且比你更容易。你以为自己的方案是固若金汤，实质上会变成马其诺防线。
安全与方便是不可兼得的，二者都想得到的方案再复杂都是空中楼阁。