Category Archives: Linux

CVE-2019-14287: Local Privilege Escalation

Yesterday, a local privilege escalation vulnerability of sudo was reported by a security researcher, Joe Vennix. The proof of concept is simple but the exploitation of that can be powerful.

$ sudo -u#-1 whoami
root

-u#-1 means that, sudo is required to run the command as the user with id equals to -1.

With merely 5 more characters (the highlighted ones) you can do a local privilege escalation for all sudo version prior to 1.8.28. Isn't that amazing (and maybe dangerous as well)? Let's dive into it and see what happens inside. sudo version 1.8.27 will be used for demonstration in this post. (It can be downloaded at https://www.sudo.ws/dist/sudo-1.8.27.tar.gz)

Given that the vulnerability is related to the command line argument, it would be a great idea to the src/parse_args.c file firstly.

Continue reading CVE-2019-14287: Local Privilege Escalation

仔细想想还是 Dockerized 吧!

The AI Lab of my mentor was running by me for quite some months. And now it's about time to hand over the docs of the internal server to graduates. Though one of which tends to lose internet connection from time to time due to its location. However, I heart that it had been moved back to university in the middle of July.

And originally, I use Microsoft Word to keep all the records and information of almost everything, but it obviously would cause some issues.

For example, one's docs version may vary from another. Yes, I've thought about to use the cloud storage with version control even. The problem is that we cannot afford the expense of cloud drive. And we could not find someone who's willing to take the charge of reimbursement. The bills have already piled up in my mentor's desk.

Besides that, to use file as docs will inevitably introduce the ugly naming, such as docs-20190807, docs-20190607 or whatever. And it would be totally disaster if to use git for version control. Despite of the unreadable commits, the filename needs to be the same, which extremely likely to be ignored to update from the git repo for some people.

Luckily, there's one instance on AliCloud (Although personally I don't really like AliCloud, but that's another story, let's save it for next time). And lots of packages that can generate static HTML from markdown have been developed these years around.

It would be easy for everyone to access docs online and because the markdown file is pure text, we can have a very good and most important, readable track of changes with git.

The final decision is to use VuePress as the static HTML generator. And to ensure a simple installation process, dockerization is the best shot at the moment. Furthermore, basic HTTP auth is needed to keep unwanted visitors out, leaving the docs only accessible to the lab.

For your convenience, this project is located at my GitHub, https://github.com/BlueCocoa/docs. It's fully prepared and dockerized with docker-compose support.

Continue reading 仔细想想还是 Dockerized 吧!

多用户 Docker 环境下 PyPi 源按需加速

这一篇算是接在上一篇Build a super fast on demand local PyPi mirror的后面吧~

这里会以 docker-compose 的方式为例子,详细写一下~不使用docker-compose的话,则也仅仅需要手动指定 pypicache 与需要这个服务的 container 到同一个 docker 网络中,这样就可以不用去找 pypicache 的 IP 地址,对最终用户透明化,不用增加额外的 pip 安装参数,即可轻松享受本地高速缓存,特别是对于大一点的文件效果更明显~

jupyterhub-docker
jupyterhub-docker

Continue reading 多用户 Docker 环境下 PyPi 源按需加速

Build a super fast on demand local PyPi mirror

  • 当公司/局域网里有多人都使用 Python 开发,并且几乎都会用到 pip 来部署环境时,虽然已经有各种镜像源了,但是下载仍受限于与外网的宽带速度,并且同样的包可能被多人下载了多次,在包较大时,重复花的时间并不值
  • 当你使用 Docker 来构建不同的 Python 应用/环境时,在测试 Dockerfile 时可能需要不断的删掉之前 build 的版本,从头开始 build 时,pip 下载与上面面临同样的问题——重复消耗不必要的时间

其一解决方案是公司/局域网内部搞一个 PyPi 的镜像源,实际上维护一个完整的镜像源相当麻烦,占用的储存空间太大,在公司/局域网的情况下,大家开发的东西、使用的技术栈相对比较固定,这就导致完整的镜像源里会有很多包其实几乎没人用。

其二的解决方案可以是预先构建好一个或多个 Docker 镜像,其中包含大家都会用到的包,剩余的一些包则在使用时才被少数需要的人安装。这种方案的缺点则是目前 Docker 服务 + 多用户方案在重启之后会丢掉已经配置过的环境,重启之后依旧需要从镜像源下载包。

那么这里相对一劳永逸的方案则是搭建一个本地的按需下载的 PyPi 镜像源,其原理则是在镜像源与公司/局域网内增加了一个高速缓存,并且由于 PyPi 已经提交分发的whl或者tar.gz是不会变的,因此不用顾虑缓存时间的设置。

最后就像这样~ 182KB/s VS. 36.4MB/s
(cache server为千兆有线链接,MacBook为802.11 AC,测试时链接速度585Mbps)

It's apparently super fast after being cached!
It's apparently super fast after being cached!

Continue reading Build a super fast on demand local PyPi mirror

A brief tutorial on setup an AI lab server for a small team

这个是在之前导师的实验室积累的一些东西,使用场景的话,是适用于2-8人左右的小团队吧,当时有两台机器,一台是放在学校机房的服务器,CPU没注意是什么,印象中是64G内存,4块P20,貌似24G显存?;另一台机器则放在办公室,主要配置的话,一颗AMD Ryzen 2700X,64G内存,再附加两块1080ti 11G,经费肯定是还做不到一人分一块GPU,部分模型的大小也不需要完全独占一块GPU。但是构建一个小型团队使用的AI Lab服务器是没问题了。

当时搭建的AI Lab服务器的主要架构如下

AI Lab Platform Architecture
AI Lab Platform Architecture

系统方面选择了Ubuntu 18.04 LTS,简单方便,毕竟是做AI不是做OS,没有任何必要引入其他方面复杂的操作。然后在这之上则是系统层面的GPU驱动,当时对应的版本为396.26,目前已经有400版本号的驱动了。接下来就是与docker对接的nvidia的runc,由这个runc去给docker内的GPU提供支持。随后当时则是使用了支持多用户的JupyterHub,当然也可以通过分配多个账号解决,这一部分和之后的部分解决方案就很多了。

Continue reading A brief tutorial on setup an AI lab server for a small team

2 Days at LinuxCon 2017

有幸获得了 HACKx 赠送的 LinuxCon 2017 门票,于是便动身参加了 LinuxCon 2017,这也是 LinuxCon 首次在国内举行,顺便也在大会上见到了 Linus Torvalds。

Linus Torvalds @LinuxCon 2017
Linus Torvalds @LinuxCon 2017

这次的 LinuxCon 实际上是三个会议,其一不用说,就是 LinuxCon 了,然后是 ContainerCon 和 CloudOpen,官方合称为 LC3。此次 LC3 的 Keynote 和各展商的 Presentation 覆盖了以下 10 个方面

  • Programming Frameworks 编程框架
  • Application Platforms 应用平台
  • VM / VIM Managers 虚机管理
  • Containers 容器
  • Operating System 操作系统
  • Virtual Machines 虚拟机
  • Network Management & Orchestration
  • Carrier Networking 运营商网络
  • Network Controller 网络控制
  • Data Plane Services 数据平面服务

在这 10 个方面上,作为支撑的则是

  • Security 安全性
  • Governance, Operations & Ecosystem 运维
  • Licensing & IPR 许可和知识产权
  • Training & Certification 培训和认证

除了 Keynote Session 之外,各展商的 Presentation 都是同时在不同会议室展开的,我只去听了其中几场

  • Much Ado About Blocking: Wait/Wake in the Linux Kernel - Davidlohr Bueso, SUSE Labs
  • Rethinking the OS: A Travel Journal - Simora Arsene, SUSE
  • MD RAID1 and NVMe: High Performance Data Duplication - Coly (Yong) Li, SUSE Linux
  • Kubernetes Bootcamp 101 - Caicloud
  • LinuxCon K8S + TensorFlow Bootcamp 101 - Caicloud

要说什么的话,这次的 LC3 给我的感觉是(大部分)围绕 Container 来进行的,包括但不限于 SUSE、Intel、VMWare、Caicloud 在内的公司都在致力于为 Containter 提供更好、更易用、更安全的体验。

这里我挑选几个印象最深的来说说吧。

首先是 SUSE 正式发布了 SUSE MicroOS(Micro stands for Microservice),官方是这样描述的,

A purpose built Operating System designed for microservice & containers and optimized for large deployments.

一个专为微服务容器打造的,且为大规模部署优化过的操作系统。

主要特点则是

  • An always up-to-date Operating System
  • An easy to manage/upgrade OS
  • Easily setup/manage a cluster of nodes
  • scalable - up to 1000s of nodes

An always up-to-date Operating System(一个总是最新的操作系统)。关于更新这一点,可能有人遇到过更新之后出现问题的情况,SUSE 在这边使用了 Atomic Upgrade(原子更新),保证了在更新期间,即使出现了问题,也能回滚到更新前的状态。接下来,SUSE 做到 always up-to-date 的方案则是,一直在后台拉取更新,然后在系统负载低时进行更新。

SUSE MicroOS 则是作为 SUSE CaaS Platform 的组成之一,剩下则是 Kubernetes 和 Container Engines。

SUSE CaaS Platform 3 Key Technology Components v1.1
SUSE CaaS Platform 3 Key Technology Components v1.1
Source: https://www.suse.com/communities/blog/suse-caas-platform-whats-buzz/

关于 SUSE CaaS Platform 的更多信息,可以参考 SUSE 官方的博客

接下来则是 Intel 的 Clear Linux 和 Clear Container 技术。需要注意的是,虽然这两个项目命名方式类似,但是实际上是两个不相干的项目。

Clear Container 技术是为了给现有的 Container 提供一个虚拟机级别(例如 VMWare)的隔离。在现有的 Container Engine 技术中,由于不同的 Container 共享的是一个 Linux Kernel,如果其中一个感染了可以取得 Kernel 代码执行权限的病毒,那么这个病毒就可以绕过 Container Engine 的隔离,感染所有正在运行的 Container。

在 Clear Container 中,Intel 目前实现了与 Docker 无缝对接,利用 Intel VT-x 实现了 Kernel 级别的隔离,因此不同的 Container 也可以运行在不同版本的 Kernel 之上。当然,虽说是无缝对接,但是实际上还是多了一层,即 Intel VT-x 那层,据 Intel 的说明,目前在内部测试出来的开销并不大,启动一个 Container 只多 20ms 的样子,但是对文件读取的开销还没有非常明确,目前是将文件映射到内存以尽可能降低这方面的开销。

Clear Linux 则是另一个项目,这个项目的目标是构造一个尽可能小的 Linux 用于 Container,并且内核模块全部使用静态链接的方式换取速度与安全,如果你有特别的需求的话,可以自己在 Clear Linux 的基础上编译内核(当然也都是静态方式)。目前 Clear Linux 的 Container 镜像仅仅 5 MB。

Jetson TX1入手(/ω\)

其实在去年12月10来号的时候,就已经决定要入手一个Jetson TX1做开发了,一方面是因为现在使用的MacBook自带的Intel(R) HD Graphics 515性能比较低,当时用waifu2x把一个720P的视频拉到了2560x1440,跑了两周多吧……另一方面是想学习一些并行计算和机器学习的技术。于是就让梅子帮我拿到了一个教育版的Jetson TX1~(我们学校那时还没有教育邮箱,不过现在可以申请啦)

实际拿到Jetson TX1是在12月30号,不过当时刷完系统,装了torch 7之后发现居然就没剩多少了

df -h
df -h

于是剁了一块SSD(下个月吃土吧_(:_」∠)_)

Continue reading Jetson TX1入手(/ω\)

iOSOpenDev的补丁~

之前写过为iOSOpenDev增加指定设备端口功能 (English ver. is here),今天在看LPI的时候,书中提到了Linux的内核升级,其中就用了patch来给内核文件打补丁。

这样的方式比起我当时给出的“自己对应目录层级”覆盖文件好多了,于是就当是学习diff和patch的使用方法,做了一个iOSOpenDev的补丁,不过我是按照1.6-2版本的iOSOpenDev做的,其他版本的没有测试。

文件在这: iOSOpenDev.patch

Usage: sudo gzip -cd iOSOpenDev.patch.gz | patch -p0

Continue reading iOSOpenDev的补丁~