| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <4753A025.2020803@ak.jp.nec.com>
Date: Mon, 03 Dec 2007 15:20:21 +0900
From: KaiGai Kohei <kaigai@...jp.nec.com>
To: Andrew Morgan <morgan@...nel.org>
CC: KaiGai Kohei <kaigai@...gai.gr.jp>, serge@...lyn.com,
"Serge E. Hallyn" <serue@...ibm.com>,
lkml <linux-kernel@...r.kernel.org>,
linux-security-module@...r.kernel.org,
Chris Wright <chrisw@...s-sol.org>,
Stephen Smalley <sds@...ch.ncsc.mil>,
James Morris <jmorris@...ei.org>, Andrew Morton <akpm@...l.org>
Subject: Re: [PATCH] capabilities: introduce per-process capability bounding
set (v10)
Andrew Morgan wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> KaiGai Kohei wrote:
>>> There is already a pam_cap module in the libcap2 package. Can we merge
>>> this functionality?
>> I think it is a good idea.
>>
>> However, this module already have a feature to modify inheritable
>> capability set.
>> How does it to be described in the "/etc/security/capability.conf"?
>>
>> One idea is like a following convention:
>>
>> # compatible configuration. We can omit "i:" at the head of line
>> cap_setfcap tak
>> # It drops any capabilities from b-set except for cap_net_raw and
>> cap_fowner
>> b:cap_net_raw,cap_fowner ymj
>> # It drops only cap_dac_override from b-set.
>> b:-cap_dac_override kaigai
>> # It drops only cap_sys_admin from b-set of any user within users group.
>> b:-cap_sys_admin group:users
>
> I like the idea of a separate line for bounds.
>
> For ease of parsing, perhaps '!' or some other symbol prefix to the line
> could be used to identify lines that refer to cap_bound?
>
> In other modules, @groupname is used to capture a group association.
>
> Lines like this should be supported:
>
> !cap_net_raw @regularusers # suppress from cap_bset
> cap_net_raw @pingers morgan # add to pI
>
> where morgan is not in group @pingers but is in group @regularusers.
The "@groupname" is intuitive convention. I also think it is good idea.
But !cap_xxx is a bit misunderstandable for me. Someone may misunderstand
this line means any capabilities except for cap_xxx.
Thus, I think that using "b:" and omittable "i:" prefix is better than "!".
In addition, what is your opinion about using "-b:" and "-i:" to represent
dropping capabilities currently they have?
There is one more uncertain case.
When a user belongs to several groups with capabilities configuration,
what capabilities are to be attached for the user?
e.g) When kaigai belong to @pingers and @paccters
b:cap_sys_pacct @paccters
b:cap_net_raw @pingers
-b:cap_dac_override,cap_net_raw kaigai
If we apply "OR" policy, kaigai get only cap_sys_pacct, because
he got cap_sys_pacct and cap_net_raw came from @paccters and @pingers
but cap_dac_override and cap_net_raw are dropped by the third line.
Thanks,
> Cheers
>
> Andrew
>
>> Thanks,
>>
>>> Cheers
>>>
>>> Andrew
>>>
>>> serge@...lyn.com wrote:
>>>> Quoting KaiGai Kohei (kaigai@...gai.gr.jp):
>>>>> Serge E. Hallyn wrote:
>>>>>> The capability bounding set is a set beyond which capabilities
>>>>>> cannot grow. Currently cap_bset is per-system. It can be
>>>>>> manipulated through sysctl, but only init can add capabilities.
>>>>>> Root can remove capabilities. By default it includes all caps
>>>>>> except CAP_SETPCAP.
>>>>> Serge,
>>>>>
>>>>> This feature makes me being interested in.
>>>>> I think you intend to apply this feature for the primary process
>>>>> of security container.
>>>>> However, it is also worthwhile to apply when a session is starting up.
>>>>>
>>>>> The following PAM module enables to drop capability bounding bit
>>>>> specified by the fifth field in /etc/passwd entry.
>>>>> This code is just an example now, but considerable feature.
>>>>>
>>>>> build and install:
>>>>> # gcc -Wall -c pam_cap_drop.c
>>>>> # gcc -Wall -shared -Xlinker -x -o pam_cap_drop.so pam_cap_drop.o -lpam
>>>>> # cp pam_cap_drop.so /lib/security
>>>>>
>>>>> modify /etc/passwd as follows:
>>>>>
>>>>> tak:x:1004:100:cap_drop=cap_net_raw,cap_chown:/home/tak:/bin/bash
>>>>> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>>>>> example:
>>>>> [kaigai@...u ~]$ ping 192.168.1.1
>>>>> PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data.
>>>>> 64 bytes from 192.168.1.1: icmp_seq=1 ttl=64 time=1.23 ms
>>>>> 64 bytes from 192.168.1.1: icmp_seq=2 ttl=64 time=1.02 ms
>>>>>
>>>>> --- 192.168.1.1 ping statistics ---
>>>>> 2 packets transmitted, 2 received, 0% packet loss, time 999ms
>>>>> rtt min/avg/max/mdev = 1.023/1.130/1.237/0.107 ms
>>>>>
>>>>> [kaigai@...u ~]$ ssh tak@...alhost
>>>>> tak@...alhost's password:
>>>>> Last login: Sat Dec 1 10:09:29 2007 from masu.myhome.cx
>>>>> [tak@...u ~]$ export LANG=C
>>>>> [tak@...u ~]$ ping 192.168.1.1
>>>>> ping: icmp open socket: Operation not permitted
>>>>>
>>>>> [tak@...u ~]$ su
>>>>> Password:
>>>>> pam_cap_bset[6921]: user root does not have 'cap_drop=' property
>>>>> [root@...u tak]# cat /proc/self/status | grep ^Cap
>>>>> CapInh: 0000000000000000
>>>>> CapPrm: 00000000ffffdffe
>>>>> CapEff: 00000000ffffdffe
>>>>> [root@...u tak]#
>>>> Neat. A bigger-stick version of not adding the account to
>>>> group wheel. I'll use that.
>>>>
>>>> Is there any reason not to have a separate /etc/login.capbounds
>>>> config file, though, so the account can still have a full name?
>>>> Did you only use that for convenience of proof of concept, or
>>>> is there another reason?
>>>>
>>>>> # BTW, I replaced the James's address in the Cc: list,
>>>>> # because MTA does not accept it.
>>>> Thanks! I don't know what happened to my alias for him...
>>>>
>>>> thanks,
>>>> -serge
>>>>
>>>>> --
>>>>> KaiGai Kohei <kaigai@...gai.gr.jp>
>>>>>
>>>>> ************************************************************
>>>>> pam_cap_drop.c
>>>>> ************************************************************
>>>>>
>>>>> /*
>>>>> * pam_cap_drop.c module -- drop capabilities bounding set
>>>>> *
>>>>> * Copyright: 2007 KaiGai Kohei <kaigai@...gai.gr.jp>
>>>>> */
>>>>>
>>>>> #include <errno.h>
>>>>> #include <pwd.h>
>>>>> #include <stdlib.h>
>>>>> #include <stdio.h>
>>>>> #include <string.h>
>>>>> #include <syslog.h>
>>>>> #include <sys/prctl.h>
>>>>> #include <sys/types.h>
>>>>>
>>>>> #include <security/pam_modules.h>
>>>>>
>>>>> #ifndef PR_CAPBSET_DROP
>>>>> #define PR_CAPBSET_DROP 24
>>>>> #endif
>>>>>
>>>>> static char *captable[] = {
>>>>> "cap_chown",
>>>>> "cap_dac_override",
>>>>> "cap_dac_read_search",
>>>>> "cap_fowner",
>>>>> "cap_fsetid",
>>>>> "cap_kill",
>>>>> "cap_setgid",
>>>>> "cap_setuid",
>>>>> "cap_setpcap",
>>>>> "cap_linux_immutable",
>>>>> "cap_net_bind_service",
>>>>> "cap_net_broadcast",
>>>>> "cap_net_admin",
>>>>> "cap_net_raw",
>>>>> "cap_ipc_lock",
>>>>> "cap_ipc_owner",
>>>>> "cap_sys_module",
>>>>> "cap_sys_rawio",
>>>>> "cap_sys_chroot",
>>>>> "cap_sys_ptrace",
>>>>> "cap_sys_pacct",
>>>>> "cap_sys_admin",
>>>>> "cap_sys_boot",
>>>>> "cap_sys_nice",
>>>>> "cap_sys_resource",
>>>>> "cap_sys_time",
>>>>> "cap_sys_tty_config",
>>>>> "cap_mknod",
>>>>> "cap_lease",
>>>>> "cap_audit_write",
>>>>> "cap_audit_control",
>>>>> "cap_setfcap",
>>>>> NULL,
>>>>> };
>>>>>
>>>>>
>>>>> PAM_EXTERN int
>>>>> pam_sm_open_session(pam_handle_t *pamh, int flags,
>>>>> int argc, const char **argv)
>>>>> {
>>>>> struct passwd *pwd;
>>>>> char *pos, *buf;
>>>>> char *username = NULL;
>>>>>
>>>>> /* open system logger */
>>>>> openlog("pam_cap_bset", LOG_PERROR | LOG_PID, LOG_AUTHPRIV);
>>>>>
>>>>> /* get the unix username */
>>>>> if (pam_get_item(pamh, PAM_USER, (void *) &username) !=
>>>>> PAM_SUCCESS || !username)
>>>>> return PAM_USER_UNKNOWN;
>>>>>
>>>>> /* get the passwd entry */
>>>>> pwd = getpwnam(username);
>>>>> if (!pwd)
>>>>> return PAM_USER_UNKNOWN;
>>>>>
>>>>> /* Is there "cap_drop=" ? */
>>>>> pos = strstr(pwd->pw_gecos, "cap_drop=");
>>>>> if (pos) {
>>>>> buf = strdup(pos + sizeof("cap_drop=") - 1);
>>>>> if (!buf)
>>>>> return PAM_SESSION_ERR;
>>>>> pos = strtok(buf, ",");
>>>>> while (pos) {
>>>>> int rc, i;
>>>>>
>>>>> for (i=0; captable[i]; i++) {
>>>>> if (!strcmp(pos, captable[i])) {
>>>>> rc = prctl(PR_CAPBSET_DROP, i);
>>>>> if (rc < 0) {
>>>>> syslog(LOG_NOTICE, "user %s could not drop
>>>>> %s (%s)",
>>>>> username, captable[i], strerror(errno));
>>>>> break;
>>>>> }
>>>>> syslog(LOG_NOTICE, "user %s drops %s\n",
>>>>> username, captable[i]);
>>>>> goto next;
>>>>> }
>>>>> }
>>>>> break;
>>>>> next:
>>>>> pos = strtok(NULL, ",");
>>>>> }
>>>>> free(buf);
>>>>> } else {
>>>>> syslog(LOG_NOTICE, "user %s does not have 'cap_drop='
>>>>> property", username);
>>>>> }
>>>>> return PAM_SUCCESS;
>>>>> }
>>>>>
>>>>> PAM_EXTERN int
>>>>> pam_sm_close_session(pam_handle_t *pamh, int flags,
>>>>> int argc, const char **argv)
>>>>> {
>>>>> /* do nothing */
>>>>> return PAM_SUCCESS;
>>>>> }
>>>>>
>>>>> ************************************************************
>>>>> -
>>>>> To unsubscribe from this list: send the line "unsubscribe
>>>>> linux-security-module" in
>>>>> the body of a message to majordomo@...r.kernel.org
>>>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>> -----BEGIN PGP SIGNATURE-----
>>> Version: GnuPG v1.4.7 (Darwin)
>>> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>>>
>>> iD8DBQFHUbHDmwytjiwfWMwRAj5uAJ9+OB8ljQlJAhKW7jxJWrIPa1k2vgCdHFL9
>>> 3zXtwGz+cVeThb53/kAmdCs=
>>> =OdM7
>>> -----END PGP SIGNATURE-----
>>> -
>>> To unsubscribe from this list: send the line "unsubscribe
>>> linux-security-module" in
>>> the body of a message to majordomo@...r.kernel.org
>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>>
>>
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.7 (Darwin)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
> iD8DBQFHUvY5+bHCR3gb8jsRAvKaAJ9Upbi+vcSoiQnf64qtubbNow4wmgCdGMBb
> UneHzcT8FDexDcFhN5c6OK4=
> =0XeM
> -----END PGP SIGNATURE-----
> -
> To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
> the body of a message to majordomo@...r.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
>
--
OSS Platform Development Division, NEC
KaiGai Kohei <kaigai@...jp.nec.com>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists