Attached is a patch which introduces a new LSM hook,
security_task_lookup. This hook allows an LSM to mediate visibility of
/proc/<pid> on a per-process level. It applies cleanly to 2.6.8.1 and
has been tested on xSeries, pSeries, and zSeries. The bsdjail lsm which
will be sent next is a user of this hook.
Please apply.
Signed-off-by: Serge E. Hallyn <[email protected]>
-serge
Attached is a patch against the security Kconfig and Makefile to support
bsdjail, as well as the bsdjail.c file itself. bsdjail offers
functionality similar to (but more limited than) the vserver patch.
A process in a jail lives under a chroot which is not vulnerable to the
well-known chdir(...)(etc)chroot(.) attack against normal chroots, and
may be locked to one ip address. For additional features, please see
Documentation/bsdjail.txt, which is included in the next patch.
The patch applies cleanly to 2.6.8.1, and has been tested on xSeries,
pSeries, and zSeries.
Please apply.
Signed-off-by: Serge E. Hallyn <[email protected]>
-serge
Attached is a patch carrying the documentation for the bsdjail LSM.
Please apply.
Signed-off-by: Serge E. Hallyn <[email protected]>
-serge
On Gwe, 2004-09-10 at 21:23, Serge Hallyn wrote:
> Attached is a patch against the security Kconfig and Makefile to support
> bsdjail, as well as the bsdjail.c file itself. bsdjail offers
> functionality similar to (but more limited than) the vserver patch.
Looking over the code the first question I would ask is that it supports
AF_INET but not AF_INET6. That seems a bit limited in todays internet
environment.
> A process in a jail lives under a chroot which is not vulnerable to the
> well-known chdir(...)(etc)chroot(.) attack against normal chroots, and
> may be locked to one ip address. For additional features, please see
> Documentation/bsdjail.txt, which is included in the next patch.
You can break out with someone co-operating from outside the jail but
that I guess is pretty harmless anyway.
Alan
Greetings Serge!
On Fri, Sep 10, 2004 at 03:23:07PM -0500, Serge Hallyn wrote:
> Attached is a patch against the security Kconfig and Makefile to support
> bsdjail, as well as the bsdjail.c file itself. bsdjail offers
> functionality similar to (but more limited than) the vserver patch.
>
> A process in a jail lives under a chroot which is not vulnerable to the
> well-known chdir(...)(etc)chroot(.) attack against normal chroots, and
> may be locked to one ip address. For additional features, please see
> Documentation/bsdjail.txt, which is included in the next patch.
sounds good, maybe linux-vserver and bsdjail can
share/utilize common code/functionality here?
(will have a look at the code soon)
also interresting enhancements might be
- private namespaces (linux-vserver uses them)
- certain virtualizations (loadavg, ...)
anyway, let me know if you are interested in
any cooperation ...
best,
Herbert
> The patch applies cleanly to 2.6.8.1, and has been tested on xSeries,
> pSeries, and zSeries.
>
> Please apply.
>
> Signed-off-by: Serge E. Hallyn <[email protected]>
>
> -serge
Quoting Alan Cox ([email protected]):
> On Gwe, 2004-09-10 at 21:23, Serge Hallyn wrote:
> > Attached is a patch against the security Kconfig and Makefile to support
> > bsdjail, as well as the bsdjail.c file itself. bsdjail offers
> > functionality similar to (but more limited than) the vserver patch.
>
> Looking over the code the first question I would ask is that it supports
Thank you for looking at it.
> AF_INET but not AF_INET6. That seems a bit limited in todays internet
> environment.
bsdjail.c in the attached version of jail.diff adds support for ipv6.
This was my first time using ipv6, so please let me know if I'm going
about it all wrong.
Right now one must choose between either an ipv4 or ipv6 interface.
Is typical ipv6 usage such that it would be preferable to be able to
specify one of each?
Compiles and tests on a Crusoe laptop.
thanks,
-serge
On Llu, 2004-09-13 at 00:33, Serge E. Hallyn wrote:
> Right now one must choose between either an ipv4 or ipv6 interface.
> Is typical ipv6 usage such that it would be preferable to be able to
> specify one of each?
Its normal to have both yes.
A more interesting question is whether all of the "which socket for
which use" stuff could be addressed by netfilter chains run at
bind/connect time ?
Quoting Alan Cox ([email protected]):
> On Llu, 2004-09-13 at 00:33, Serge E. Hallyn wrote:
> > Right now one must choose between either an ipv4 or ipv6 interface.
> > Is typical ipv6 usage such that it would be preferable to be able to
> > specify one of each?
>
> Its normal to have both yes.
>
> A more interesting question is whether all of the "which socket for
> which use" stuff could be addressed by netfilter chains run at
> bind/connect time ?
You mean to add two new netfilter hooks? Would these then replace the
LSM hooks?
-serge
On Mon, 2004-09-13 at 05:56, Alan Cox wrote:
> On Llu, 2004-09-13 at 00:33, Serge E. Hallyn wrote:
> > Right now one must choose between either an ipv4 or ipv6 interface.
> > Is typical ipv6 usage such that it would be preferable to be able to
> > specify one of each?
>
> Its normal to have both yes.
The attached version supports simultaneous ipv4 and ipv6 addresses.
(Though only one of each)
Signed-off-by: Serge Hallyn <[email protected]>
On Mon, Sep 13, 2004 at 06:20:05PM -0500, Serge Hallyn wrote:
> +#define in_use(x) (x->jail_flags & IN_USE)
> +#define set_in_use(x) (x->jail_flags |= IN_USE)
> +
> +#define got_network(x) (x->jail_flags & (GOT_IPV4 | GOT_IPV6))
> +#define got_ipv4(x) (x->jail_flags & (GOT_IPV4))
> +#define got_ipv6(x) (x->jail_flags & (GOT_IPV6))
> +#define set_ipv4(x) (x->jail_flags |= GOT_IPV4)
> +#define set_ipv6(x) (x->jail_flags |= GOT_IPV6)
> +#define unset_got_ipv4(x) (x->jail_flags &= ~GOT_IPV4)
> +#define unset_got_ipv6(x) (x->jail_flags &= ~GOT_IPV6)
> +
> +#define get_task_security(task) (task->security)
> +#define get_inode_security(inode) (inode->i_security)
> +#define get_sock_security(sock) (sock->sk_security)
> +#define get_file_security(file) (file->f_security)
> +#define get_ipc_security(ipc) (ipc->security)
> +
> +#define jail_of(proc) (get_task_security(proc))
> +
> +#define set_task_security(task,data) task->security = data
> +#define set_inode_security(inode,data) inode->i_security = data
> +#define set_sock_security(sock,data) sock->sk_security = data
> +#define set_file_security(file,data) file->f_security = data
> +#define set_ipc_security(ipc,data) ipc.security = data
Hi Serge,
Do you really need all thoses macros ?
It seems to me that's too much macros for stuff which are easy
to write and to understand.
Just my 2cents,
--
Tab
> Hi Serge,
>
> Do you really need all thoses macros ?
> It seems to me that's too much macros for stuff which are easy
> to write and to understand.
Hi,
the _security macros are there because I'm working with 3 ways of stacking
security modules which share the ->security fields, where these can
turn into static inlines. Being able to just change the defines has
been very helpful.
I guess I've grown used to seeing them so I didn't even notice. I
will send out a new patch with the #defines removed tomorrow if that's
deemed helpful.
thanks,
-serge
* Serge E. Hallyn ([email protected]) wrote:
> > Do you really need all thoses macros ?
> > It seems to me that's too much macros for stuff which are easy
> > to write and to understand.
>
> the _security macros are there because I'm working with 3 ways of stacking
> security modules which share the ->security fields, where these can
> turn into static inlines. Being able to just change the defines has
> been very helpful.
>
> I guess I've grown used to seeing them so I didn't even notice. I
> will send out a new patch with the #defines removed tomorrow if that's
> deemed helpful.
For now they are fine as they are.
thanks,
-chris
--
Linux Security Modules http://lsm.immunix.org http://lsm.bkbits.net