All of lore.kernel.org
 help / color / mirror / Atom feed
From: KaiGai Kohei <kaigai@ak.jp.nec.com>
To: Andrew Morgan <morgan@kernel.org>
Cc: KaiGai Kohei <kaigai@kaigai.gr.jp>,
	serge@hallyn.com, "Serge E. Hallyn" <serue@us.ibm.com>,
	lkml <linux-kernel@vger.kernel.org>,
	linux-security-module@vger.kernel.org,
	Chris Wright <chrisw@sous-sol.org>,
	Stephen Smalley <sds@epoch.ncsc.mil>,
	James Morris <jmorris@namei.org>, Andrew Morton <akpm@osdl.org>
Subject: Re: [PATCH] capabilities: introduce per-process capability	bounding set (v10)
Date: Mon, 03 Dec 2007 15:20:21 +0900	[thread overview]
Message-ID: <4753A025.2020803@ak.jp.nec.com> (raw)
In-Reply-To: <4752F63B.6070606@kernel.org>

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@hallyn.com wrote:
>>>> Quoting KaiGai Kohei (kaigai@kaigai.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@masu ~]$ 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@masu ~]$ ssh tak@localhost
>>>>> tak@localhost's password:
>>>>> Last login: Sat Dec  1 10:09:29 2007 from masu.myhome.cx
>>>>> [tak@masu ~]$ export LANG=C
>>>>> [tak@masu ~]$ ping 192.168.1.1
>>>>> ping: icmp open socket: Operation not permitted
>>>>>
>>>>> [tak@masu ~]$ su
>>>>> Password:
>>>>> pam_cap_bset[6921]: user root does not have 'cap_drop=' property
>>>>> [root@masu tak]# cat /proc/self/status | grep ^Cap
>>>>> CapInh: 0000000000000000
>>>>> CapPrm: 00000000ffffdffe
>>>>> CapEff: 00000000ffffdffe
>>>>> [root@masu 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@kaigai.gr.jp>
>>>>>
>>>>> ************************************************************
>>>>>     pam_cap_drop.c
>>>>> ************************************************************
>>>>>
>>>>> /*
>>>>>  * pam_cap_drop.c module -- drop capabilities bounding set
>>>>>  *
>>>>>  * Copyright: 2007 KaiGai Kohei <kaigai@kaigai.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@vger.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@vger.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@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 
> 


-- 
OSS Platform Development Division, NEC
KaiGai Kohei <kaigai@ak.jp.nec.com>

  reply	other threads:[~2007-12-03  6:24 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-11-26 20:09 [PATCH] capabilities: introduce per-process capability bounding set (v10) Serge E. Hallyn
2007-11-27  3:42 ` Andrew Morgan
2007-11-27 18:42   ` Serge E. Hallyn
2007-12-01  1:20 ` KaiGai Kohei
2007-12-01  3:58   ` serge
2007-12-01 19:10     ` Andrew Morgan
2007-12-02  3:29       ` KaiGai Kohei
2007-12-02 18:15         ` Andrew Morgan
2007-12-03  6:20           ` KaiGai Kohei [this message]
2007-12-02  1:28     ` KaiGai Kohei
2007-12-04  4:28 ` KaiGai Kohei
2007-12-04  6:14   ` Andrew Morgan
2007-12-04 15:19     ` KaiGai Kohei
2007-12-04 20:17       ` serge
2007-12-06  2:01         ` KaiGai Kohei
2007-12-05 15:31       ` Andrew Morgan
2007-12-06  2:13         ` KaiGai Kohei
2007-12-06  5:39           ` Andrew Morgan
2007-12-06  8:36             ` KaiGai Kohei
2007-12-07  0:51               ` KaiGai Kohei
2007-12-07  6:14                 ` Andrew Morgan

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4753A025.2020803@ak.jp.nec.com \
    --to=kaigai@ak.jp.nec.com \
    --cc=akpm@osdl.org \
    --cc=chrisw@sous-sol.org \
    --cc=jmorris@namei.org \
    --cc=kaigai@kaigai.gr.jp \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-security-module@vger.kernel.org \
    --cc=morgan@kernel.org \
    --cc=sds@epoch.ncsc.mil \
    --cc=serge@hallyn.com \
    --cc=serue@us.ibm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.