当我在solaris 11.0上执行时:
pfiles /proc/PROCESSID
结果是流程信息,一小部分输出是我感兴趣的:
4: S_IFSOCK mode:0666 dev:543,0 ino:46228 uid:0 gid:0 size:0
O_RDWR|O_NONBLOCK
SOCK_STREAM
SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(128480)
sockname: AF_INET6 ::ffff:10.10.50.28 port: 22
peername: AF_INET6 ::ffff:10.16.6.150 port: 55504
我的pfiles / proc / PROCESSID进程是sshd会话本身。
我的问题是一个进程ID,如何从内核代码中获取此(pfiles)信息?
在查看 struct proc 时,我找不到能给我这些数据的东西。
是否有一个指向struct的指针,该指针包含进程上进程占用的所有打开文件。 PROC?
我还执行了 truss pfiles / proc / PROCESSID 但找不到确切的调用
答案 0 :(得分:2)
如果您look in /usr/include/sys/user.h
,您会看到可以在当前流程的p_user.u_finfo
结构中找到打开的文件信息。
走这个结构并非易事。只需look at what the proc
filesystem code has to do to look up the attributes of just one open file descriptor。需要大量锁定 - 在运行时不能简单地遍历数据结构。
而且,以下内容超出了问题的范围,但重要的是......
对于它的价值,你正在做的事情是行不通的。它在技术上和法律上都存在根本缺陷。
您要做的事情 - 跟踪共享用户帐户的用户 - 无论如何都是毫无价值的。您永远无法证明这是因为某个登录会话执行了一些代码执行的代码,因为登录该会话的用户故意运行该代码。 因为有权访问该帐户的任何用户都可以修改共享帐户的环境,以便恶意软件由其他人运行。它们可以使它看起来像一个输入命令。
Shared credentials and accounts violate nonrepudiation.这是使用您的自定义内核跟踪可能产生的任何数据的不可逾越的法律缺陷 - 即使您设法生成一个万无一失的系统,这是不可能的。
如果我已登录共享帐户,您可以从不证明我运行的代码是故意运行的。
嗯,这并不完全正确 - 如果你有完美的审核,你可以追踪用户所做的每件事情到磁盘上修改的字节,你可以。在这种情况下,“完美”意味着这些用户无法访问任何更改审计系统的任何部分。
但如果你已经有了完善的审计,你就不需要编写内核模块来尝试实现它。
当然,要证明你没有完美的审计是不可能的,因为你无法证明你没有漏洞。
看到问题?
我们回到“你不能证明我故意这样做了。”
使用操作系统提供的审核服务会好得多。无论你提出什么,对于任何聪明的坏演员证明“谁做了”都没有用 - 就像有人想出一种方法将恶意代码插入到另一个用户的会话中。操作系统审核将足以吸引任何不知道如何掩盖其踪迹的人。
但是,当涉及共享账户时,你将无法证明任何知道他正在做什么的坏演员。如果你无法证明这一点,你甚至可能根本无法对你怀疑的人做任何事情。因为真正知道自己正在做什么的人能够将明显的责任归咎于无辜的人 - 如果他们不能隐瞒或破坏不良行为的证据的话。
如果您发现共享的.profile
文件中有一行,在某个日期之后将敏感数据通过电子邮件发送到一次性电子邮件帐户,您会怎么做,但仅当登录来自某个IP地址?
共享该帐户的任何一个用户都可以将其放在那里。
世界上没有任何审计系统可以解决这个问题,除非它是完美的和跟踪每个文件的变化。
如果您尝试保护的数据很重要,那么通过编写自定义内核模块来解决问题的任何人都需要发展大脑并解决真正的问题 - 共享用户帐户。摆脱它们。
有一个原因可以解释为什么每个安全指南都说不使用共享帐户,而且我见过的每次安全审核都会让使用共享帐户的人失败。