Date: Thu, 8 Aug 2013 19:50:33 +0900 From: Tetsuo Handa <penguin-kernel@...ove.SAKURA.ne.jp> To: segoon@...nwall.com Cc: twaugh@...hat.com, amwang@...hat.com, linux-security-module@...r.kernel.org, kernel-hardening@...ts.openwall.com Subject: Re: [RFC] KPortReserve : kernel version of portreserve utility Vasily Kulikov wrote: > Wait, it restrict the port to a *program*, not a user/group/security > domain? It means *any* user may run this program and obtain the port. > Is it intentional behaviour? Yes, it is intentional behaviour. Below is the background of proposing this functionality. I sometimes hear of troubles caused by local port reservation conflicts. For example, active/standby high-availability services failed to failover because the migrating application failed to bind() to port number which the application uses was already used by other applications (e.g. portmap , vsftpd ) when failover occurred. For another example, some enterprise application failed to start because the application failed to bind() to port numbers which the application uses was already used by other applications when the application starts. Regarding autobind cases, /proc/sys/net/ipv4/ip_local_reserved_ports can prevent troubles shown above. But regarding non-autobind cases, /proc/sys/net/ipv4/ip_local_reserved_ports cannot. While portreserve utility is provided for managing non-autobind cases, it is not available in RHEL4/5. While it is available in RHEL6, it is not race-free. Thus, I decided to write a trivial, race-free kernel module which restricts local ports to the programs. The applications which I care are likely running as root user. Thus, I'm not feeling that this module needs to restrict the port to a user/group/security domain. > I guess it would be MUCH more useful to > allow some port to this specific user, NOT a program. For most daemons > we have separate user accounts (SELinux contexts in some distros, > whatever), so it makes sense to limit the port to a UID/GID (or LSM's > security context). I know. Skilled users can use more complicated implementations which restrict the port to a user/group/security domain. The goal of this module is to allow unskilled users to use this module as simple/easy as /proc/sys/net/ipv4/ip_local_reserved_ports . > d_absolute_path() may fail in case of not only ENOMEM, but also EINVAL. Indeed. I truncated too much. Well, if the system entered into a situation where d_absolute_path() returns EINVAL, program's pathname can never be calculated and we would need to choose one from any program which got EINVAL cannot bind() the reserved port and any program which got EINVAL can bind() the reserved port if answer to Question 5 is "no". (Question 5) Do we want to distinguish interpreter/busybox programs? I worry that the use of /proc/self/exe is too coarse in some systems. Say, there are four programs. (1) /sbin/prog1 starts with "#! /usr/bin/perl" and calls bind() with port 50000 and the EADDRINUSE error is fatal. (2) /bin/prog2 starts with "#! /usr/bin/perl" and calls bind() with randomly chosen non-0 port numbers but the EADDRINUSE error is not fatal. (3) /bin/prog3 is a symlink to a multicall-binary and calls bind() with port 60000 and the EADDRINUSE error is fatal. (4) /bin/prog4 is a symlink to a multicall-binary and calls bind() with randomly chosen non-0 port numbers but the EADDRINUSE error is not fatal. The content of /proc/self/exe cannot distinguish (1) and (2) because they are both /usr/bin/perl . But users might expect this module to return 0 for (1) and return EADDRINUSE for (2). The content of /proc/self/exe cannot distinguish (3) and (4) if they are symlinks to the same multicall-binary. But users might expect this module to return 0 for (3) and return EADDRINUSE for (4). To distinguish such cases, I need to use the pathname passed to do_execve() rather than the content of /proc/self/exe .
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.