openwall
Sponsored Links
Sponsored Links
Secleted [ 0 ] software to compare
Results 1 - 15 of about 9
Openwall tcb suite 1.0
Openwall tcb suite package contains core components of our tcb suite implementing the alternative password shadowing scheme. more>>
Openwall tcb suite package contains core components of our tcb suite implementing the alternative password shadowing scheme on Owl.
It is being made available separately from Owl primarily for use by other distributions. Note that you need to have the password hashing framework introduced with crypt_blowfish patched into glibc to compile and use this.
The package consists of three components: pam_tcb, libnss_tcb, and libtcb.
pam_tcb is a PAM module which supersedes pam_unix. It also implements the tcb password shadowing scheme.
The tcb scheme allows many core system utilities (passwd(1) being the primary example) to operate with little privilege. libnss_tcb is the accompanying NSS module. libtcb contains code shared by the PAM and NSS modules and is also used by user management tools on Owl due to our shadow suite patches.
<<lessIt is being made available separately from Owl primarily for use by other distributions. Note that you need to have the password hashing framework introduced with crypt_blowfish patched into glibc to compile and use this.
The package consists of three components: pam_tcb, libnss_tcb, and libtcb.
pam_tcb is a PAM module which supersedes pam_unix. It also implements the tcb password shadowing scheme.
The tcb scheme allows many core system utilities (passwd(1) being the primary example) to operate with little privilege. libnss_tcb is the accompanying NSS module. libtcb contains code shared by the PAM and NSS modules and is also used by user management tools on Owl due to our shadow suite patches.
Download (0.040MB)
Added: 2005-12-30 License: GPL (GNU General Public License) Price:
1395 downloads
Openwall GNU/*/Linux 2.0
Openwall GNU/*/Linux is a security-enhanced operating system with Linux and GNU software as its core. more>>
Openwall GNU/*/Linux (or Owl for short) is a security-enhanced operating system with Linux and GNU software as its core, compatible with other major distributions of GNU/*/Linux. Openwall GNU/*/Linux is intended as a server platform. And, of course, it is free.
Main features:
- While we value quality above feature set, Owl does indeed offer a number of features besides just trying to be more secure.
- Most obviously, Owl can be used as a base for installing whatever software is generally available for GNU/*/Linux systems. It offers some compatibility (read below) for software packages found in or developed for other major Linux distributions, such as Red Hat Linux.
- Additionally, being a server platform, Owl will include a growing set of integrated Internet services.
- Owl includes a complete build environment capable to re-build the entire system from source with one simple command ("make buildworld"). (This is explained in more detail below.)
- Owl supports multiple architectures (currently x86, SPARC, and Alpha), as this lets you use it in more cases and helps us catch certain classes of software bugs earlier, thus improving the reliability of Owl packages.
Security:
- Owl combines several approaches to reduce the number and/or impact of flaws in its software components and impact of flaws in third-party software that one might install on the system.
- The primary approach used is proactive source code review for several classes of software vulnerabilities. However, because of the large amount of code, theres a certain level of "importance" for a software component or a part thereof to be audited. - Currently, only pieces of code which are typically run with privileges greater than those of a regular user and/or typically process data obtained over a network are audited before the corresponding software component is included. This covers relevant code paths in many of the system libraries, all SUID/ SGID programs, all daemons and network services. Other software may be audited when it is already a part of Owl. Potential problems found during the audit are fixed or, in some pathological cases, may prevent the software component from being included. In general, code quality and privilege management are always considered when theres a choice between implementations of a feature. As the project evolves, many of the software components will be replaced with ones of our own.
- When packaged for Owl, the software components are configured or, when necessary, modified in order to provide safe defaults, apply the least privilege principle, and introduce privilege separation. The use of safe defaults, where optional and potentially dangerous features need to be turned on explicitly, lets us audit the pieces of code used in in the default configuration in a more thorough way. Extra systems administration facilities ("owl-control") are provided for managing system features such as the optional SUID/SGID binaries independently from installing the corresponding packages. Every Owl package will have its audit status documented to allow for risk assessment.
- While source code review is the preferred way to deal with software vulnerabilities, it cant be applied in all cases. Typically, when insecure third-party software is installed on an otherwise secure system, "the game" is lost. The only thing an operating system can guarantee is that potential unauthorized access would be limited to those privileges granted to the software in question. However, in the recent years, a number of approaches were developed which reduce the likelihood and/or may reduce the impact of successful real-world attacks on insecure third-party software. Owl will use some of those "hardening" approaches in various parts of the system.
- Owl uses "strong" cryptography within its core components, and already includes some security policy enforcement (proactive password checking with "pam_passwdqc", password and account expiration, network address- based access control) and integrity checking ("mtree") capabilities. It is one of our goals to provide a wide range of security tools with Owl, available for use "out of the box".
Enhancements:
- After many Owl-current snapshots, Owl 2.0 release is finally out.
- Owl 2.0 is built around Linux kernel 2.4.32-ow1, glibc 2.3.6 (with our security enhancements), GCC 3.4.5, and recent versions of over 100 other packages.
- It offers binary- and package-level compatibility for most packages intended for Red Hat Enterprise Linux 4 (RHEL4) and Fedora Core 3 (FC3), as well as for many FC4 packages.
- Additionally, Owl 2.0 uses our new installer, making installation a lot easier than it used to be for Owl 1.1 and below.
<<lessMain features:
- While we value quality above feature set, Owl does indeed offer a number of features besides just trying to be more secure.
- Most obviously, Owl can be used as a base for installing whatever software is generally available for GNU/*/Linux systems. It offers some compatibility (read below) for software packages found in or developed for other major Linux distributions, such as Red Hat Linux.
- Additionally, being a server platform, Owl will include a growing set of integrated Internet services.
- Owl includes a complete build environment capable to re-build the entire system from source with one simple command ("make buildworld"). (This is explained in more detail below.)
- Owl supports multiple architectures (currently x86, SPARC, and Alpha), as this lets you use it in more cases and helps us catch certain classes of software bugs earlier, thus improving the reliability of Owl packages.
Security:
- Owl combines several approaches to reduce the number and/or impact of flaws in its software components and impact of flaws in third-party software that one might install on the system.
- The primary approach used is proactive source code review for several classes of software vulnerabilities. However, because of the large amount of code, theres a certain level of "importance" for a software component or a part thereof to be audited. - Currently, only pieces of code which are typically run with privileges greater than those of a regular user and/or typically process data obtained over a network are audited before the corresponding software component is included. This covers relevant code paths in many of the system libraries, all SUID/ SGID programs, all daemons and network services. Other software may be audited when it is already a part of Owl. Potential problems found during the audit are fixed or, in some pathological cases, may prevent the software component from being included. In general, code quality and privilege management are always considered when theres a choice between implementations of a feature. As the project evolves, many of the software components will be replaced with ones of our own.
- When packaged for Owl, the software components are configured or, when necessary, modified in order to provide safe defaults, apply the least privilege principle, and introduce privilege separation. The use of safe defaults, where optional and potentially dangerous features need to be turned on explicitly, lets us audit the pieces of code used in in the default configuration in a more thorough way. Extra systems administration facilities ("owl-control") are provided for managing system features such as the optional SUID/SGID binaries independently from installing the corresponding packages. Every Owl package will have its audit status documented to allow for risk assessment.
- While source code review is the preferred way to deal with software vulnerabilities, it cant be applied in all cases. Typically, when insecure third-party software is installed on an otherwise secure system, "the game" is lost. The only thing an operating system can guarantee is that potential unauthorized access would be limited to those privileges granted to the software in question. However, in the recent years, a number of approaches were developed which reduce the likelihood and/or may reduce the impact of successful real-world attacks on insecure third-party software. Owl will use some of those "hardening" approaches in various parts of the system.
- Owl uses "strong" cryptography within its core components, and already includes some security policy enforcement (proactive password checking with "pam_passwdqc", password and account expiration, network address- based access control) and integrity checking ("mtree") capabilities. It is one of our goals to provide a wide range of security tools with Owl, available for use "out of the box".
Enhancements:
- After many Owl-current snapshots, Owl 2.0 release is finally out.
- Owl 2.0 is built around Linux kernel 2.4.32-ow1, glibc 2.3.6 (with our security enhancements), GCC 3.4.5, and recent versions of over 100 other packages.
- It offers binary- and package-level compatibility for most packages intended for Red Hat Enterprise Linux 4 (RHEL4) and Fedora Core 3 (FC3), as well as for many FC4 packages.
- Additionally, Owl 2.0 uses our new installer, making installation a lot easier than it used to be for Owl 1.1 and below.
Download (407.7MB)
Added: 2006-02-16 License: GPL (GNU General Public License) Price:
1349 downloads
Openwall Linux kernel patch 2.4.35-ow2
Openwall Linux kernel patch is a collection of security-related features for the Linux kernel. more>>
Openwall Linux kernel patch is a collection of security-related features for the Linux kernel, all configurable via the new Security options configuration section. In addition to the new features, some versions of the patch contain various security fixes.
The number of such fixes changes from version to version, as some are becoming obsolete (such as because of the same problem getting fixed with a new kernel release), while other security issues are discovered.
Non-executable user stack area.
Most buffer overflow exploits are based on overwriting a functions return address on the stack to point to some arbitrary code, which is also put onto the stack. If the stack area is non-executable, buffer overflow vulnerabilities become harder to exploit.
Another way to exploit a buffer overflow is to point the return address to a function in libc, usually system(). This patch also changes the default address that shared libraries are mmap()ed at to make it always contain a zero byte. This makes it impossible to specify any more data (parameters to the function, or more copies of the return address when filling with a pattern), -- in many exploits that have to do with ASCIIZ strings.
However, note that this patch is by no means a complete solution, it just adds an extra layer of security. Many buffer overflow vulnerabilities will remain exploitable a more complicated way, and some will even remain unaffected by the patch. The reason for using such a patch is to protect against some of the buffer overflow vulnerabilities that are yet unknown.
Also, note that some buffer overflows can be used for denial of service attacks (usually in non-respawning daemons and network clients). A patch like this cannot do anything against that.
It is important that you fix vulnerabilities as soon as they become known, even if youre using the patch. The same applies to other features of the patch (discussed below) and their corresponding vulnerabilities.
Restricted links in /tmp.
Ive also added a link-in-+t restriction, originally for Linux 2.0 only, by Andrew Tridgell. Ive updated it to prevent from using a hard link in an attack instead, by not allowing regular users to create hard links to files they dont own, unless they could read and write the file (due to group permissions). This is usually the desired behavior anyway, since otherwise users couldnt remove such links theyve just created in a +t directory (unfortunately, this is still possible for group-writable files) and because of disk quotas.
Unfortunately, this may break existing applications.
Restricted FIFOs in /tmp.
In addition to restricting links, you might also want to restrict writes into untrusted FIFOs (named pipes), to make data spoofing attacks harder. Enabling this option disallows writing into FIFOs not owned by the user in +t directories, unless the owner is the same as that of the directory or the FIFO is opened without the O_CREAT flag.
Restricted /proc.
This was originally a patch by route that only changed the permissions on some directories in /proc, so you had to be root to access them. Then there were similar patches by others. I found them all quite unusable for my purposes, on a system where I wanted several admins to be able to see all the processes, etc, without having to su root (or use sudo) each time. So I had to create my own patch that I include here.
This option restricts the permissions on /proc so that non-root users can see their own processes only, and nothing about active network connections, unless theyre in a special group. This groups id is specified via the gid= mount option, and is 0 by default. (Note: if youre using identd, you will need to edit the inetd.conf line to run identd as this special group.) Also, this disables dmesg(8) for the users. You might want to use this on an ISP shell server where privacy is an issue. Note that these extra restrictions can be trivially bypassed with physical access (without having to reboot).
When using this part of the patch, most programs (ps, top, who) work as desired -- they only show the processes of this user (unless root or in the special group, or running with the relevant capabilities on 2.2+), and dont complain they cant access others. However, theres a known problem with w(1) in recent versions of procps, so you should apply the included patch to procps if this applies to you.
Enhancements:
- This revision adds a fix for the "parent process death signal" vulnerability in the Linux kernel.
- It also adds two security hardening features, both enabled by default: restricted access to VM86 mode (specific to 32-bit x86) and restricted zero page mappings (generic).
<<lessThe number of such fixes changes from version to version, as some are becoming obsolete (such as because of the same problem getting fixed with a new kernel release), while other security issues are discovered.
Non-executable user stack area.
Most buffer overflow exploits are based on overwriting a functions return address on the stack to point to some arbitrary code, which is also put onto the stack. If the stack area is non-executable, buffer overflow vulnerabilities become harder to exploit.
Another way to exploit a buffer overflow is to point the return address to a function in libc, usually system(). This patch also changes the default address that shared libraries are mmap()ed at to make it always contain a zero byte. This makes it impossible to specify any more data (parameters to the function, or more copies of the return address when filling with a pattern), -- in many exploits that have to do with ASCIIZ strings.
However, note that this patch is by no means a complete solution, it just adds an extra layer of security. Many buffer overflow vulnerabilities will remain exploitable a more complicated way, and some will even remain unaffected by the patch. The reason for using such a patch is to protect against some of the buffer overflow vulnerabilities that are yet unknown.
Also, note that some buffer overflows can be used for denial of service attacks (usually in non-respawning daemons and network clients). A patch like this cannot do anything against that.
It is important that you fix vulnerabilities as soon as they become known, even if youre using the patch. The same applies to other features of the patch (discussed below) and their corresponding vulnerabilities.
Restricted links in /tmp.
Ive also added a link-in-+t restriction, originally for Linux 2.0 only, by Andrew Tridgell. Ive updated it to prevent from using a hard link in an attack instead, by not allowing regular users to create hard links to files they dont own, unless they could read and write the file (due to group permissions). This is usually the desired behavior anyway, since otherwise users couldnt remove such links theyve just created in a +t directory (unfortunately, this is still possible for group-writable files) and because of disk quotas.
Unfortunately, this may break existing applications.
Restricted FIFOs in /tmp.
In addition to restricting links, you might also want to restrict writes into untrusted FIFOs (named pipes), to make data spoofing attacks harder. Enabling this option disallows writing into FIFOs not owned by the user in +t directories, unless the owner is the same as that of the directory or the FIFO is opened without the O_CREAT flag.
Restricted /proc.
This was originally a patch by route that only changed the permissions on some directories in /proc, so you had to be root to access them. Then there were similar patches by others. I found them all quite unusable for my purposes, on a system where I wanted several admins to be able to see all the processes, etc, without having to su root (or use sudo) each time. So I had to create my own patch that I include here.
This option restricts the permissions on /proc so that non-root users can see their own processes only, and nothing about active network connections, unless theyre in a special group. This groups id is specified via the gid= mount option, and is 0 by default. (Note: if youre using identd, you will need to edit the inetd.conf line to run identd as this special group.) Also, this disables dmesg(8) for the users. You might want to use this on an ISP shell server where privacy is an issue. Note that these extra restrictions can be trivially bypassed with physical access (without having to reboot).
When using this part of the patch, most programs (ps, top, who) work as desired -- they only show the processes of this user (unless root or in the special group, or running with the relevant capabilities on 2.2+), and dont complain they cant access others. However, theres a known problem with w(1) in recent versions of procps, so you should apply the included patch to procps if this applies to you.
Enhancements:
- This revision adds a fix for the "parent process death signal" vulnerability in the Linux kernel.
- It also adds two security hardening features, both enabled by default: restricted access to VM86 mode (specific to 32-bit x86) and restricted zero page mappings (generic).
Download (0.034MB)
Added: 2007-08-15 License: GPL (GNU General Public License) Price:
800 downloads
Sentry Firewall CD 1.5.0 RC16
Sentry Firewall CD-ROM is a Linux based bootable CD-ROM suitable for use as an inexpensive and easy to maintain Firewall or IDS. more>>
Sentry Firewall CD-ROM is a Linux-based bootable CDROM suitable for use as an inexpensive and easy to maintain firewall, server, or IDS(Intrusion Detection System) Node. The system is designed to be immediately configurable for a variety of different operating environments via a configuration file located on a floppy disk, a local hard drive, and/or a network via HTTP(S), FTP, SFTP, or SCP.
The Sentry Firewall CD is a complete Linux system that runs off of an initial ramdisk, much like a floppy-based system, and a CD. The default kernel is a current 2.4.x series kernel with various Netfilter patches applied. An OpenWall-patched current 2.2.x kernel is also available on the CD.
Booting from the CDROM is a fairly familiar process. The BIOS execs the bootloader(Syslinux) - which then displays a bootprompt and loads the kernel and ramdisk into memory. Once the kernel is running, the ramdisk is then mounted as root(/). At this point our configuration scripts are run(written in perl) that configure the rest of the system. It is the job of these configure scripts to put the various startup and system files into the proper location using either what is declared in the configuration file(sentry.conf) or the system defaults located in the /etc/default directory.
Most of the critical files used at boot time can be replaced with your own copy when declared in the configuration file. This is essentially how we allow the user to configure the system using his/her own configuration and init files.
All of the binaries, files, scripts, etc, used to create the CD-ROM are also available on the CD-ROM. So, with a little practice, you can easily build and customize your own bootable Sentry Firewall CD.
Main features:
- Current Linux Kernel: 2.4.28-ow1
- OpenWall security patch(-ow1).
- StrongSwan.
- Ebtables bridge+netfilter patch.
- Linux-WLAN modules.
- MPPE patch.
- Modules-off patch [ More Info | Patch ]
- iptables v1.2.11.
- ebtables v2.0.6.
- OpenVPN.
- IProute2 utilities.
- Vconfig.
- PPTP Client/Server.
- Zebra
- Snort IDS v2.2.0
- Scanlogd
- OpenSSH and OpenSSL
- net-snmp
- Webmin
- NMap
- Many other daemons and binaries you may need -- Apache, Sendmail, Squid, Perl, BIND (static/chroot), and more.
<<lessThe Sentry Firewall CD is a complete Linux system that runs off of an initial ramdisk, much like a floppy-based system, and a CD. The default kernel is a current 2.4.x series kernel with various Netfilter patches applied. An OpenWall-patched current 2.2.x kernel is also available on the CD.
Booting from the CDROM is a fairly familiar process. The BIOS execs the bootloader(Syslinux) - which then displays a bootprompt and loads the kernel and ramdisk into memory. Once the kernel is running, the ramdisk is then mounted as root(/). At this point our configuration scripts are run(written in perl) that configure the rest of the system. It is the job of these configure scripts to put the various startup and system files into the proper location using either what is declared in the configuration file(sentry.conf) or the system defaults located in the /etc/default directory.
Most of the critical files used at boot time can be replaced with your own copy when declared in the configuration file. This is essentially how we allow the user to configure the system using his/her own configuration and init files.
All of the binaries, files, scripts, etc, used to create the CD-ROM are also available on the CD-ROM. So, with a little practice, you can easily build and customize your own bootable Sentry Firewall CD.
Main features:
- Current Linux Kernel: 2.4.28-ow1
- OpenWall security patch(-ow1).
- StrongSwan.
- Ebtables bridge+netfilter patch.
- Linux-WLAN modules.
- MPPE patch.
- Modules-off patch [ More Info | Patch ]
- iptables v1.2.11.
- ebtables v2.0.6.
- OpenVPN.
- IProute2 utilities.
- Vconfig.
- PPTP Client/Server.
- Zebra
- Snort IDS v2.2.0
- Scanlogd
- OpenSSH and OpenSSL
- net-snmp
- Webmin
- NMap
- Many other daemons and binaries you may need -- Apache, Sendmail, Squid, Perl, BIND (static/chroot), and more.
Download (107MB)
Added: 2005-05-19 License: GPL (GNU General Public License) Price:
1619 downloads
phpass 0.1
phpass is a portable PHP password hashing framework. more>>
phpass is a portable PHP password hashing framework.
This is a portable public domain password hashing framework for use in PHP applications. It is meant to work with PHP 3 and above, and it has actually been tested with PHP 3.0.18, 4.3.x, 4.4.x, and 5.0.x so far.
The preferred (most secure) hashing method supported by phpass is the OpenBSD-style Blowfish-based bcrypt, also supported with our public domain crypt_blowfish package (for C applications), and known in PHP as CRYPT_BLOWFISH, with a fallback to BSDI-style extended DES-based hashes, known in PHP as CRYPT_EXT_DES, and a last resort fallback to an MD5-based variable iteration count password hashing method implemented in phpass itself.
To ensure that the fallbacks will never occur, the PHP Hardening-Patch may be used. The Hardening-Patch integrates crypt_blowfish into the PHP interpreter such that bcrypt is available for use by PHP scripts even if the host system lacks support for it. Hopefully, future versions of PHP will do the same.
Included in the package are a PHP source file implementing the PasswordHash PHP class, a tiny PHP application demonstrating the use of the PasswordHash class, and a C re-implementation of the last resort password hashing method (used for testing the correctness of the primary implementation only).
Enhancements:
- The framework test program has been enhanced in numerous ways, and a minor bug which had no practical impact in the framework itself has been fixed.
<<lessThis is a portable public domain password hashing framework for use in PHP applications. It is meant to work with PHP 3 and above, and it has actually been tested with PHP 3.0.18, 4.3.x, 4.4.x, and 5.0.x so far.
The preferred (most secure) hashing method supported by phpass is the OpenBSD-style Blowfish-based bcrypt, also supported with our public domain crypt_blowfish package (for C applications), and known in PHP as CRYPT_BLOWFISH, with a fallback to BSDI-style extended DES-based hashes, known in PHP as CRYPT_EXT_DES, and a last resort fallback to an MD5-based variable iteration count password hashing method implemented in phpass itself.
To ensure that the fallbacks will never occur, the PHP Hardening-Patch may be used. The Hardening-Patch integrates crypt_blowfish into the PHP interpreter such that bcrypt is available for use by PHP scripts even if the host system lacks support for it. Hopefully, future versions of PHP will do the same.
Included in the package are a PHP source file implementing the PasswordHash PHP class, a tiny PHP application demonstrating the use of the PasswordHash class, and a C re-implementation of the last resort password hashing method (used for testing the correctness of the primary implementation only).
Enhancements:
- The framework test program has been enhanced in numerous ways, and a minor bug which had no practical impact in the framework itself has been fixed.
Download (0.004MB)
Added: 2006-09-08 License: GPL (GNU General Public License) Price:
1144 downloads
stephanie 3.0
stephanie is a program for hardening OpenBSD for multiuser environments. more>>
stephanie is a program for hardening OpenBSD for multiuser environments.
Mmmmm, OpenBSD. Functional, secure, free. With an emphasis on security and integrated cryptography, it carries an excellent reputation for plain old "you-just-cant-hack-this-ness". Not perfect, but nothing is, at least theyre not wearing suits and lying to you.
There are a few roles where i believe OpenBSD fits perfectly. One of these is in multiuser environments, where you have large numbers of possibly malicious users with local access. Here the OpenBSD teams commitment to auditing and fixing code provides a level trust in the environment which is hard to find elsewhere. Also, their efforts to provide integrated cryptography means setting up secure access is easy. So, lets take advantage of the freely available source and tailor it to our specific needs.
Details:
In Phrack 54, route|Mike Schiffman wrote a series of patches for OpenBSD 2.4 for Trusted Path Execution (TPE). Stephanie brings a modified version of these up to speed for OpenBSD 2.8 - 3.0, along with some additional features. A trusted path is one where the parent directory is owned by root and is neither group or other writeable. The TPE works off an internal list of trusted user ids. If a given user tries to execute a file not in a trusted path, and their user id is not in the kernels trusted list, they are denied execution privileges. In real terms, this means they cant download, compile and run krad-sploit.c.
In addition to the TPE, a series of privacy patches came along too. Originally supplied as patches for the individual utilities, these are now implemented through kvm(3), and honour trusted users (ie, trusted users are allowed to see all system information). As a practical example, this means that untrusted users will only be able to see information about processes they own, and the stat tools (netstat, iostat, vmstat, etc) will generally be broken for them. It has been pointed out that by going through trying to kill every possible process id you can find other users processes, but you cant really gain any information on them, so this is not really a great concern.
The original TPE patches had one known way of bypassing the execution restrictions, which was using shell redirection to allow arbitrary interpreted language scripts to be run (perl, sh, etc). This has been fixed up, but could possibly be a big pain in the ass, so please pay attention. When an interpreter is invoked, like most things, it creates a new process group with a job count of one. When a series of commands are connected via the | character on the command line, all the commands belong to the same process group and the job count represents the number of commands eg ps -ax | grep something | awk {print $1} has a job count of three, and the ps, grep and awk processes all belong to the same process group.
The one exception to this is when a user logs in, where we find their shell has its job count set to zero. So how can we use this to prevent shell redirection for a given set of programs? We need to be able to distinguish between ordinary commands and interpreters. At the moment this is done by setting the immutable flag on them. So, in kern_exec(), if we find an untrusted user executing something with the immutable flag set and a job count greater than zero, we flag the process as being potentially dodgy. Then in other system calls we disallow read()ing from fd 0 (stdin) and things like dup2(0, n) if the process has been flagged.
There are two main disadvantages to this. First is the system will need to be brought down to single user mode if the interpreter needs to be patched, and secondly, people will have a hard time suing to an untrusted user. Of course, when a user has shell, they can still type any commands that could otherwise be placed in a shell script, but at the least, this will raise the bar a bit.
Finally, Stephanie brings restricted symbolic links, ala the openwall patches for linux. As time permits, im still working on adding additional features, and will add bits of the openwall stuff i like. The basic goal is to add an extra layer of security without being a monumental pain in the ass to legitimate users, so some things wont be there. I havent added the additional hard link restrictions of the openwall patch, but will do something about this later as time permits.
Installing:
Step by step instructions are presented in the install guide which comes with the source. Read it all first, but its reasonably straight forward. It would be a good idea to read the original article (local copy) if you havent already.
Its distributed under the original two clause BSD license, mess with it all you want, but dont get cranky at me if it breaks something.
You can also read the tpe_adm(8) man page online.
<<lessMmmmm, OpenBSD. Functional, secure, free. With an emphasis on security and integrated cryptography, it carries an excellent reputation for plain old "you-just-cant-hack-this-ness". Not perfect, but nothing is, at least theyre not wearing suits and lying to you.
There are a few roles where i believe OpenBSD fits perfectly. One of these is in multiuser environments, where you have large numbers of possibly malicious users with local access. Here the OpenBSD teams commitment to auditing and fixing code provides a level trust in the environment which is hard to find elsewhere. Also, their efforts to provide integrated cryptography means setting up secure access is easy. So, lets take advantage of the freely available source and tailor it to our specific needs.
Details:
In Phrack 54, route|Mike Schiffman wrote a series of patches for OpenBSD 2.4 for Trusted Path Execution (TPE). Stephanie brings a modified version of these up to speed for OpenBSD 2.8 - 3.0, along with some additional features. A trusted path is one where the parent directory is owned by root and is neither group or other writeable. The TPE works off an internal list of trusted user ids. If a given user tries to execute a file not in a trusted path, and their user id is not in the kernels trusted list, they are denied execution privileges. In real terms, this means they cant download, compile and run krad-sploit.c.
In addition to the TPE, a series of privacy patches came along too. Originally supplied as patches for the individual utilities, these are now implemented through kvm(3), and honour trusted users (ie, trusted users are allowed to see all system information). As a practical example, this means that untrusted users will only be able to see information about processes they own, and the stat tools (netstat, iostat, vmstat, etc) will generally be broken for them. It has been pointed out that by going through trying to kill every possible process id you can find other users processes, but you cant really gain any information on them, so this is not really a great concern.
The original TPE patches had one known way of bypassing the execution restrictions, which was using shell redirection to allow arbitrary interpreted language scripts to be run (perl, sh, etc). This has been fixed up, but could possibly be a big pain in the ass, so please pay attention. When an interpreter is invoked, like most things, it creates a new process group with a job count of one. When a series of commands are connected via the | character on the command line, all the commands belong to the same process group and the job count represents the number of commands eg ps -ax | grep something | awk {print $1} has a job count of three, and the ps, grep and awk processes all belong to the same process group.
The one exception to this is when a user logs in, where we find their shell has its job count set to zero. So how can we use this to prevent shell redirection for a given set of programs? We need to be able to distinguish between ordinary commands and interpreters. At the moment this is done by setting the immutable flag on them. So, in kern_exec(), if we find an untrusted user executing something with the immutable flag set and a job count greater than zero, we flag the process as being potentially dodgy. Then in other system calls we disallow read()ing from fd 0 (stdin) and things like dup2(0, n) if the process has been flagged.
There are two main disadvantages to this. First is the system will need to be brought down to single user mode if the interpreter needs to be patched, and secondly, people will have a hard time suing to an untrusted user. Of course, when a user has shell, they can still type any commands that could otherwise be placed in a shell script, but at the least, this will raise the bar a bit.
Finally, Stephanie brings restricted symbolic links, ala the openwall patches for linux. As time permits, im still working on adding additional features, and will add bits of the openwall stuff i like. The basic goal is to add an extra layer of security without being a monumental pain in the ass to legitimate users, so some things wont be there. I havent added the additional hard link restrictions of the openwall patch, but will do something about this later as time permits.
Installing:
Step by step instructions are presented in the install guide which comes with the source. Read it all first, but its reasonably straight forward. It would be a good idea to read the original article (local copy) if you havent already.
Its distributed under the original two clause BSD license, mess with it all you want, but dont get cranky at me if it breaks something.
You can also read the tpe_adm(8) man page online.
Download (0.014MB)
Added: 2006-03-10 License: GPL (GNU General Public License) Price:
1326 downloads
crypt_blowfish 1.0.2
crypt_blowfish is a modern password hashing for your software and your servers. more>>
crypt_blowfish is a modern password hashing for your software and your servers.
This is an implementation of a modern password hashing algorithm, based on the Blowfish block cipher, provided via the crypt(3) and a reentrant interface. It is compatible with bcrypt (version 2a) by Niels Provos and David Mazieres, as used in OpenBSD.
The most important property of bcrypt (and thus crypt_blowfish) is that it is adaptable to future processor performance improvements, allowing you to arbitrarily increase the processing cost of checking a password while still maintaining compatibility with your older password hashes. Already now bcrypt hashes you would use are several orders of magnitude stronger than traditional Unix DES-based or FreeBSD-style MD5-based hashes.
Today, a number of other operating systems, besides OpenBSD, support bcrypt password hashes, with Niels original implementation, with this implementation (crypt_blowfish), or otherwise. These systems include recent versions of FreeBSD and NetBSD, Solaris 10, and indeed the Linux distributions which have integrated crypt_blowfish (see below for a list). Only some of these systems use bcrypt for newly set passwords by default, though.
This code comes from John the Ripper password cracker, and is placed in the public domain to let you use this on your system, as a part of a software package, or anywhere else to improve security, ensure compatibility, or for any other purpose.
Theres no license to worry about, not even a BSD-style copyright.
You can use the provided routines in your own packages or link them into a C library. Hooks for linking into GNU libc are provided. Note that simply adding this code into your libc is probably not enough to make your system use the new password hashing algorithm. Changes to passwd(1), PAM modules, or whatever else your system uses will likely be needed as well. These are not a part of this package, but theres pam_tcb in the Openwall GNU/*/Linux (Owl) tcb package which uses the password hashing framework provided by crypt_blowfish, and there are the Owl shadow suite patches (in particular, the crypt_gensalt patch) available from our CVSweb server.
<<lessThis is an implementation of a modern password hashing algorithm, based on the Blowfish block cipher, provided via the crypt(3) and a reentrant interface. It is compatible with bcrypt (version 2a) by Niels Provos and David Mazieres, as used in OpenBSD.
The most important property of bcrypt (and thus crypt_blowfish) is that it is adaptable to future processor performance improvements, allowing you to arbitrarily increase the processing cost of checking a password while still maintaining compatibility with your older password hashes. Already now bcrypt hashes you would use are several orders of magnitude stronger than traditional Unix DES-based or FreeBSD-style MD5-based hashes.
Today, a number of other operating systems, besides OpenBSD, support bcrypt password hashes, with Niels original implementation, with this implementation (crypt_blowfish), or otherwise. These systems include recent versions of FreeBSD and NetBSD, Solaris 10, and indeed the Linux distributions which have integrated crypt_blowfish (see below for a list). Only some of these systems use bcrypt for newly set passwords by default, though.
This code comes from John the Ripper password cracker, and is placed in the public domain to let you use this on your system, as a part of a software package, or anywhere else to improve security, ensure compatibility, or for any other purpose.
Theres no license to worry about, not even a BSD-style copyright.
You can use the provided routines in your own packages or link them into a C library. Hooks for linking into GNU libc are provided. Note that simply adding this code into your libc is probably not enough to make your system use the new password hashing algorithm. Changes to passwd(1), PAM modules, or whatever else your system uses will likely be needed as well. These are not a part of this package, but theres pam_tcb in the Openwall GNU/*/Linux (Owl) tcb package which uses the password hashing framework provided by crypt_blowfish, and there are the Owl shadow suite patches (in particular, the crypt_gensalt patch) available from our CVSweb server.
Download (0.023MB)
Added: 2006-05-23 License: Public Domain Price:
1251 downloads
Bastard 34c
Bastard is virtual server oriented patchset, containing essential elements for building virtual server container machines. more>>
Bastard is virtual server oriented patchset, containing essential elements for building virtual server container machines.
It includes a CTX-VS patch, squashfs for creating a small template server, lufs and bme for easily creating overlayed filesystems on top of the template, and honeynet- inspired extensions to enhance monitoring of hosted servers.
Bastard project also includes VPN extensions like OpenSWAN, MPPE, and CIPE to enable direct access to hosted virtual servers in situations where IPs are scarce.
Enhancements:
- The softirq changes were backed off.
- The openwall patch was updated.
<<lessIt includes a CTX-VS patch, squashfs for creating a small template server, lufs and bme for easily creating overlayed filesystems on top of the template, and honeynet- inspired extensions to enhance monitoring of hosted servers.
Bastard project also includes VPN extensions like OpenSWAN, MPPE, and CIPE to enable direct access to hosted virtual servers in situations where IPs are scarce.
Enhancements:
- The softirq changes were backed off.
- The openwall patch was updated.
Download (MB)
Added: 2007-01-03 License: GPL (GNU General Public License) Price:
1025 downloads
msulogin 0.9.1
msulogin is a sulogin for multiple root accounts. more>>
msulogin is a sulogin for multiple root accounts.
sulogin is the single user mode login program used to force the console user to login under a root account before a shell is started.
Unlike other implementations of sulogin, this one supports having multiple root accounts on a system.
msulogin has been developed as a part of Owl and is being made available separately primarily for use by other distributions. Currently, msulogin supports only systems with getspnam.
<<lesssulogin is the single user mode login program used to force the console user to login under a root account before a shell is started.
Unlike other implementations of sulogin, this one supports having multiple root accounts on a system.
msulogin has been developed as a part of Owl and is being made available separately primarily for use by other distributions. Currently, msulogin supports only systems with getspnam.
Download (0.005MB)
Added: 2006-03-15 License: GPL (GNU General Public License) Price:
1318 downloads
Secleted [ 0 ] software to compare
- Page: 1 of 1
- 1
Copyright Notice:
Software piracy is theft, Using crack, password, serial numbers, registration codes, key generators is illegal and prevent future software development. The above openwall search only lists software in full, demo and trial versions for free download. Download links are directly from our mirror sites or publisher sites, torrent files or links from rapidshare.com, yousendit.com or megaupload.com are not allowed
