在使用Linux的过程中,经常会遇到各种用户ID(user identifier, UID)和组ID(group identifier, GID),Linux也是通过对这些ID的管理实现的自主访问控制(discretionary access control, DAC)。
作者:Vamei 出处:http://www.cnblogs.com/vamei 欢迎转载,也请保留这段声明。谢谢! 我们在Linux的概念与体系,多次提及进程的重要性。Python的os包中有查询和修改进程信息的函数。学习Python的这些工具也有助于理解Linux体系。 进程信息 os包中相关函数如下: uname() 返回操作系统相关信息。类似于Linux上的uname命令。 umask() 设置该进程创建文件时的权限mask。类似于Linux上的umask命令,见Linux文件管理背景知识 get
Linux的用户在登录(login)之后,就带有一个用户身份(user ID, UID)和一个组身份(group ID, GID)。在Linux文件管理背景知识中,我们又看到,每个文件又有九位的权限说明,用来指明该文件允许哪些用户执行哪些操作(读、写或者执行)。 (参考Linux文件管理背景知识) 一般来说,Linux的用户信息保存在/etc/passwd中,组信息保存在/etc/group中,文件的每一行代表一个用户/组。早期的Linux将密码以名码的形式保存在/etc/passwd中,而现在则多以暗码(
suid即set user id,是一种授予文件的权限类型,它允许用户使用者以文件所有者的权限来执行文件。需要这种特殊权限的场景在Linux下很常见。 已知的可以用来提权的Linux可执行文件有: CopyNmap、Vim、find、Bash、More、Less、Nano、cp 比如常用的ping命令。ping需要发送ICMP报文,而这个操作需要发送Raw Socket。在Linux 2.2引入CAPABILITIES前,使用Raw Socket是需要root权限的(当然不是说引入CAPABILITIES就不需要权限了,而是可以通过其他方法解决,这个后说),所以你如果在一些老的系统里ls -al $(which ping),可以发现其权限是-rwsr-xr-x,其中有个s位,这就是suid:
在刚开始使用docker volume挂载数据卷的时候,经常出现没有权限的问题。 这里通过遇到的问题来理解docker容器用户uid的使用,以及了解容器内外uid的映射关系。
默认情况下,容器中的进程以 root 用户权限运行,并且这个 root 用户和宿主机中的 root 是同一个用户。听起来是不是很可怕,因为这就意味着一旦容器中的进程有了适当的机会,它就可以控制宿主机上的一切!本文我们将尝试了解用户名、组名、用户 id(uid)和组 id(gid)如何在容器内的进程和主机系统之间映射,这对于系统的安全来说是非常重要的。说明:本文的演示环境为 Ubuntu 16.04(下图来自互联网)。
前几天我在代码审计知识星球里发表了一个介绍nmap利用interactive模式提权的帖子:
通常来说,Linux运行一个程序,是使用当前运行这个程序的用户权限,这当然是合理的。但是有一些程序比较特殊,比如我们常用的ping命令。
本篇继续安全系列之介绍,继续学习用户空间安全!本系列内容比较多,需要一步步的跟进。上期学习了android Linux安全介绍,下篇继续介绍android framwork层安全。
本地用户空间层在 Android 操作系统的安全配置中起到重要作用。 不理解在该层上发生了什么,就不可能理解在系统中如何实施安全架构决策。 在本章中,我们的主题是 Android 引导过程和文件系统特性的,并且描述了如何在本地用户空间层上保证安全性。
笔者在前文《理解 docker 容器中的 uid 和 gid》介绍了 docker 容器中的用户与宿主机上用户的关系,得出的结论是:docker 默认没有隔离宿主机用户和容器中的用户。如果你已经了解了 Linux 的 user namespace 技术(参考《Linux Namespace : User》),那么自然会问:docker 为什么不利用 Linux user namespace 实现用户的隔离呢?事实上,docker 已经实现了相关的功能,只是默认没有启用而已。笔者将在本文中介绍如何配置 docker 来隔离容器中的用户。 说明:本文的演示环境为 Ubuntu 16.04。
本篇继续安全系列之介绍,继续学习linux安全!,上期学习了android系统构建介绍,下期将会了解用户空间之安全。
作为最广为人知的开源项目之一,Linux 已经被证明是一个安全,可信和稳定的软件,全世界数千人对它进行研究,攻击和打补丁。 不出所料,Linux 内核是 Android 操作系统的基础[3]。 Android 不仅依赖于 Linux 的进程,内存和文件系统管理,它也是 Android 安全架构中最重要的组件之一。 在 Android 中,Linux 内核负责配置应用沙盒,以及规范一些权限。
Android的内核就是Linux,所以Android获取root其实和Linux获取root权限是一回事儿。
理解用户名、组名、用户ID(UID)和组ID(GID)在容器内运行的进程与主机系统之间的映射是构建安全系统的重要一环。如果没有提供其他选项,容器中的进程将以root用户身份执行(除非在Dockerfile中提供了不同的UID)。本文将解释这一工作原理,如何正确授予权限,并提供示例加以说明。
setuid()用来重新设置执行目前进程的用户识别码. 不过, 要让此函数有作用, 其有效的用户识别码必须为0(root). 在Linux 下, 当root 使用setuid()来变换成其他用户识别码时, root 权限会被抛弃, 完全转换成该用户身份, 也就是说, 该进程往后将不再具有可setuid()的权利, 如果只是向暂时抛弃root 权限, 稍后想重新取回权限, 则必须使用seteuid().
capabilities将系统root权限按功能单元划分,使用者按需打开/关闭相关权限,比基于UID的权限控制方式更精细。
本文介绍Python的os包中有查询和修改进程信息的函数,Python的这些工具符合Linux系统的相关概念,所以可以帮助理解Linux体系。
在linux 2.2版本之前,当内核对进程进行权限验证的时候,可以将进程划分为两类:privileged(UID=0)和unprivilege(UID!=0)。其中privileged的进程拥有所有内核权限,而unprivileged则根据如可执行文件的权限(effective UID, effective GID,supplementary group等)进行判断。
Linux是一个多用户的操作系统,引入用户,可以更加方便管理Linux服务器,系统默认需要以一个用户的身份登入,而且在系统上启动进程也需要以一个用户身份去运行,用户可以限制某些进程对特定资源的权限控制。
每个用户对其拥有的文件具有控制权,同时,用户又属于由一个或多个用户组成的用户组。用户组成员由文件和目录的所有者授予对文件和目录的访问权限。如此设计可保证每个用户的操作是独立的,不会影响到其他用户。 i
继续Android安全系列之介绍,继续学习框架安全!本系列内容比较多,需要一步步的跟进。上期学习了android 用户空间层安全介绍,下篇继续介绍android framwork层安全。
如我们在第1.2节中所描述的那样,应用程序框架级别上的安全性由 IPC 引用监视器实现。 在 4.1 节中,我们以 Android 中使用的进程间通信系统的描述开始,讲解这个级别上的安全机制。 之后,我们在 4.2 节中引入权限,而在 4.3 节中,我们描述了在此级别上实现的权限实施系统。
Linux是一个多用户的操作系统,为了实现资源分派及出于安全的考虑,必须对用户进行不同权限的分配。用户组便于更高效地管理用户权限。 用户操作Linux需要经过三个步骤的权限认证: Authentication:认证 Authorization:授权 Accouting:审计 用户及用户组 用户UID 管理员:root, 0 普通用户:1-65535 系统用户:1-499, 1-999(centos7) 作用:对守护进程获取资源进行权限分配 登录用户:500+, 1000+ 用户组GID 管理员组:root
本文的讨论围绕一个 java.lang.SecurityException 展开,异常的关键词是权限 android.permission.INTERACT_ACROSS_USERS_FULL。
在后台运行的进程不一定是守护进程!一个进程要成为守护进程,必须做到以下两点:
Linux沿用了Unix文件权限的方法,允许用户和组根据每个文件和目录的安全性设置来访问文件。 用户权限通过创建用户时分配的用户ID(UID)来跟踪的。每个用户有唯一的ID,但是登录时用的不是UID,而是登录名。 7.1.1 /etc/passwd 文件 这个文件将用户的登录名匹配到对应的UID中,还包含了一些与用户相关的信息。 root用户账户是Linux系统的管理员,UID是0. 有些账户是系统账户:系统上运行的各种服务进程访问资源用的特殊账户。 所有运行在后台的服务都需要用一个系统用户账户登录到lin
-f:强制删除用户,即使用户当前已登录; -r:删除用户的同时,删除与用户相关的所有文件
贴一个试验代码, 子进程直接获取锁, 若获取不到则输出错误; 父进程睡3秒后退出.
玩过安卓的朋友应该都对 root 这个名词不陌生,曾几何时,一台 root 过的手机是发烧友标配;对于开发者来说,root 后的手机是黑灰产外挂的温床,是想要极力避免和打击的目标;而对于安全研究人员来说,root 则意味着更多 —— Towelroot、PingPongRoot、DirtyC0w、ReVent,那些有趣的漏洞和精妙的利用,承载了不少的汗水和回忆。
如果要投票在 Kubernetes 中很重要,但又最容易被初学者忽略的字段,那么我一定投给 SecurityContext。从 Security Context(安全上下文)的名字就可得知它和安全有关,那么它是如何控制容器安全的?又是如何实现的?本文我们就来探索一下 SecurityContext 这个字段。
SEAndroid 是一套安全机制,实现的主要目的是为了是Android系统更安全。 SELinux是被设计为一个灵活的可配置的MAC机制。 SEAndroid 是将SELinux 移植到Android 上的产物,可以看成SELinux 辅以一套适用于Android 的策略。
2019年07月20日,Linux正式修复了一个本地内核提权漏洞。通过此漏洞,攻击者可将普通权限用户提升为Root权限。
在Linux中,拥有root的权限等于拥有了无上权利,但是会被selinux限制。
本文档介绍在CentOS 7系统中利用带有suid权限的程序提权从而获取root shell的方法。
双十一快要来临了,安卓三个版本已近更新完毕,打包上线,所以最近在疯狂的写博客、欢迎大家前来讨论问题,互相学习o!!! 今天和大家分享一下—Android系统信息与安全机制–
安卓有一套自己的安全权限机制,大部分来自linux的权限机制,某些地方也做了延伸,比如linux中的用户概念,在安卓上来说就相当于app。对于一些刚学习安卓的同学来说,如果之前也没有了解过linux的
对于大部分 Kubernetes 用户来说,安全是无关紧要的,或者说没那么紧要,就算考虑到了,也只是敷衍一下,草草了事。实际上 Kubernetes 提供了非常多的选项可以大大提高应用的安全性,只要用好了这些选项,就可以将绝大部分的攻击抵挡在门外。为了更容易上手,我将它们总结成了几个最佳实践配置,大家看完了就可以开干了。当然,本文所述的最佳安全实践仅限于 Pod 层面,也就是容器层面,于容器的生命周期相关,至于容器之外的安全配置(比如操作系统啦、k8s 组件啦),以后有机会再唠。
Kubernetes v1.25引入了仅适用于无状态Pod的用户命名空间支持。在Kubernetes 1.28中解除了这个限制,经过了1.27版本的一些设计更改。
存在问题: 那么多小伙伴想root,root后好处多多你懂的,那么开发的小伙伴最想关心的是安全机制问题。 解决方案: 我们就以此来了解一下Android 安全机制 安卓有一套自己的安全权限机制,大部分来自linux的权限机制,某些地方也做了延伸,比如linux中的用户概念,在安卓上来说就相当于app。对于一些刚学习安卓的同学来说,如果之前也没有了解过linux的权限概念,对于安卓的这个安全机制也会比较迷茫,看到一篇文章对于android的这个安全权限机制写的还算不错,推荐初学的同学阅读一下。当然如果某些部
豌豆贴心提醒,本文阅读时间7分钟 没有绝对的安全 在上一篇文章《linux服务器安全配置实例(一)》中介绍了我对ssh服务的一些常用的安全配置和性能优化。 其实ssh服务是我们进入服务器的一扇大门,这扇大门是提供正常人使用钥匙打开后进屋的。而对于一些恶意的小伙伴,他们会使用一些非法的方式,比如走窗户、暴力开锁等去不经过我们的同意就进屋大肆破坏。 走窗户:通过一些系统的0day漏洞或者第三方服务以及软件的漏洞溢出或者注入,在服务器中运行恶意的代码来得到登陆权限。 暴力开锁:通过一些暴力破解软件,暴力破
以下是对用户和组信息的举例。 /etc/shadow 中的口令信息为加密存储,不举例。
| 导语 外部存储作为开发中经常接触的一个重要系统组成,在Android历代版本中,有过许许多多重要的变更。我也曾疑惑过,为什么一个简简单单外部存储,会存在存在这么多奇奇怪怪的路径:/sdcard、/mnt/sdacrd、/storage/extSdCard、/mnt/shell/emulated/0、/storage/emulated/0、/mnt/shell/runtime/default/emulated/0…其实,这背后代表了一项项技术的成熟与发布:模拟外部存储、多用户、运行时权限… 一、各版本外部
在Linux系统中,每个用户都有一个唯一的用户ID(User ID),用于标识和管理用户的权限和资源访问。有时候,我们需要更改用户ID,可能是为了解决冲突、重组用户组或其他管理需求。本文将详细介绍如何在Linux中更改用户ID的几种方法。
在每一个 Kubernetes 节点中,运行着 kubelet,负责为 Pod 创建销毁容器,kubelet 预定义了 API 接口,通过 GRPC 从指定的位置调用特定的 API 进行相关操作。而这些 CRI 的实现者,如 cri-o, containerd 等,通过调用 runc 创建出容器。runc 功能相对单一,即针对特定的配置,构建出容器运行指定进程,它不能直接用来构建镜像,kubernetes 依赖的如 cri-o 这类 CRI,在 runc 基础上增加了通过 API 管理镜像,容器等功能。
在写《[apue] 进程控制那些事儿》/"进程创建"/"更改进程用户 ID 和组 ID"一节时,发现 setreuid 更新实际用户 ID (RUID) 或有效用户 ID (EUID) 时,保存的设置用户 ID (saved set-user-id SUID) 只会随 EUID 变更,并不像 man 上说的会随 RUID 变更 (man setreuid):
Linux系统使用一个专门的文件来将用户的登录名匹配到对应的UID值。这个文件就是 /etc/passwd文件,它包含了一些与用户有关的信息。如下:
NFS是Network FileSystem的缩写,即网络文件系统,它可以实现挂载远程电脑上的设备到本地从而像访问本地磁盘一样操作,有点类似于windows 的网上邻居。是SUN公司1984年开发的,v1版本只在SUN公司内部使用过,v2, v3, v4是公开版本,一般红帽5默认是v3版本,红帽6默认目前最新的v4版本。
领取专属 10元无门槛券
手把手带您无忧上云