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
 
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Date:	Fri, 04 Apr 2008 21:22:42 +0900
From:	Tetsuo Handa <penguin-kernel@...ove.SAKURA.ne.jp>
To:	akpm@...ux-foundation.org, linux-kernel@...r.kernel.org,
	linux-security-module@...r.kernel.org
Subject: [TOMOYO #7 00/30] TOMOYO Linux 1.6.0 released

What is TOMOYO Linux for?

  It is userland applications' charge to keep processes under control.
  This includes that userland applications restrict what programs are
  permitted to execute and what files are permitted to read/write
  by the application.
  Thus, the kernel does whatever asked by the userland applications.

  But userland applications often make mistakes such as buffer overflow,
  OS command injection, directory traversal etc.
  As a result, they can't always keep processes under control.

  TOMOYO Linux is developed to take partial charge of keeping processes
  under control, by teaching the kernel what programs are
  permitted to execute and what files are permitted to read/write
  by the application and letting the kernel check it once again.

Can TOMOYO Linux coexist with SELinux, SMACK, AppArmor etc. ?

  Yes. TOMOYO Linux 1.x is not using LSM because I want don't want to disable
  different access control implementations.

  TOMOYO Linux is good at dealing with the subject's request chains,
  while LSM is good at dealing with object's life-cycle.

What are new features of this release?

  This release reinforced execution parameter checks.

  Introduced execute handler mechanism.

    The usage of TOMOYO Linux is that understand what programs are executed and
    what files are opened by individual applications and let the kernel
    enforce them. Thus, assuming that all programs needed by individual
    applications are known by the time of enforcing, attempts to execute
    not ever observed application (e.g. /bin/sh) are considered to be attacks.

    Some shellcode (an exploit code used to execute /bin/sh) attempts to
    execute /bin/sh until the execution succeeds. One of such shellcodes is
    Samba's trans2open exploit. It attempts to execute /bin/sh from infinite
    loop. As a result, just rejecting execute request of /bin/sh triggers
    CPU power consumption problem (all CPU powers are eaten by the shellcode's
    infinite loop).

    But by using execute handler, you can run different programs instead of
    just rejecting execute request to redirect the process to somewhere else.

    This redirection mechanism is useful for deploying on demand honey pot.
    You can provide regular service in peacetime, and you can redirect
    the attacker trying to start /bin/sh to honey pot in wartime.

    Also, since the fact that a program which is different from the requested
    one is executed by execute handler is not notified to the caller process,
    you can use execute handler as a transparent validation interface
    like "Web Application Firewall" or "AntiVirus". You can monitor
    parameters passed to execve() and stdio to drop unwanted parameters or
    reject the execution of the program requested by the caller process.

  Introduced "struct linux_bprm" checks.

    Proper codes tends to setting up argv[] and envp[] when executing
    a new program. But shellcodes tend to not setting up argv[] and envp[]
    when executed using buffer overflows.
    Thus, it became possible to require specific argv[] and envp[] values
    when executing a program.

  Introduced environment variable names checks.

    Some environment variables (e.g. LD_PRELOAD) are used by attackers to make
    the application behave differently.
    Thus, it became possible to restrict acceptable environment variable's
    names passed to execve().

  And various usability enhancement like more detailed access logs and
  policy management by non root user.

Is TOMOYO Linux architecture independent?

  Yes. I think TOMOYO Linux doesn't contain architecture dependent code.
  TOMOYO Linux touches only surface of the kernel code.

Are older kernels supported?

  Yes. From 2.4.30 to 2.4.36 and from 2.6.11 to 2.6.25-rc7 are supported.
  Also, various distributions' latest kernels are supported.

Where's the web page?

  http://elinux.org/TomoyoLinux
  http://tomoyo.sourceforge.jp/wiki-e/?WhatIs
  http://sourceforge.jp/projects/tomoyo/document/fosdem2008.pdf

  TOMOYO Linux is compact and suits well to PC servers and embedded systems.
  There is a TOMOYO Linux presentation at CELF Embedded Linux Conference 2008
  held in California from April 15th to the 17th.

Thank you.

--
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

Powered by Openwall GNU/*/Linux Powered by OpenVZ