From: "Javier Juan Martínez Cabezón" <tazok.id0@gmail.com>
To: gentoo-hardened@lists.gentoo.org
Subject: Re: [gentoo-hardened] New Server, considering hardened, need pointers to tfm...
Date: Mon, 12 Dec 2011 16:23:21 +0100 [thread overview]
Message-ID: <CAD98N_Hgm-MZCs2kTOF3zwNFfbcXba8E=Gvse=r0KGzc0puQGQ@mail.gmail.com> (raw)
In-Reply-To: <20111212140825.73b06f80.ma1l1ists@yahoo.co.uk>
[-- Attachment #1: Type: text/plain, Size: 3631 bytes --]
About this*:
> What for after the main install, password changes (I use scripts
> allowed via sudo for that and monitor mounts globally but the monitoring
> could be improved like grsecs offering), some programs require it during
> install but not many, none on my OpenBSD mail and web servers.
*
>
> It's very bad idea to use sudo with scripts, in openbsd and everywhere.
There are a lot of documentation about this question in the web.
> Another thing that I try to do as a better method of TPE which is a
> breeze on OpenBSD and sometimes I find myself working against Linux
> developersน is to make it so that any writeable area of the filesystem
> is mounted noexec and mounts have the least priviledges required.
The TPE in openbsd relies in the trustness of root, trusted is only
feasible if nobody could reach root account (and daemons and suid binaries
can still reach it in openbsd). Until openbsd doesn't implement mandatory
controls and privilege separation (a.k.a posix capabilities) TPE will never
be trusted under him .
Other problem is script interpretation, you don't need any exec mounted
partition to launch a exploit, just a simple perl myhorribleexploit.pl does
it.
In linux you can check under rbac if a script to get interpreted is trusted
or not.
> I'm in the process of attempting to complete this on Linux rather than
> just /home etc. but on OpenBSD and the plan for single user linux
> systems is to remount for updates, which is done in a controlled
> fashion.
Again, What is exactly controlled fashion?. It gets never controlled
because EXEC mount privilege is not needed to launch exploits and for this
reason make TPE useless.
> but I probably should have just made them single user/auto-login. Bigger
> problems on OpenBSD servers (no devfs) are ttys for multi-user systems
> or multiple ssh users needing tty permission changes, otherwise only
> sftp works for all other users, which could be a feature for
> me atleast ;-). Originally I was going to try mounting /dev seperately
> but the book Absolute OpenBSD Unix for the practical paranoid said
> you couldn't, I guess it would need to be built into the kernel to boot.
> There's also secure knocking that runs commands that may not need ttys
> but I think they have to be pre-ordained, but maybe not.
If I remember correctly in openbsd exists too TIOCSTI and TIOCCONS ioctls,
one allows root to send commands to user tty (hijacking) and the other one
to spy it, how did you control under openbsd without mandatory controls?
> Starting with the actual bug, on OpenBSD everything is off untill you
> enable it like arch linux but their hotplugd allows you to easily edit
> the commands and so mount options. Of course their are things like
> devmon for Linux but the real issue was if a security policy tried to
> stop introduction of executable code by users and then someone used the
> install scripts and set up say ubuntu with udev by default then a user
> could make a directory owned by root on an ext2 usb possibly name
> it .exe and then execute their program violating the security policy
> and possibly without the admins realising, it's that not caring about
> security while developing that OpenBSD for obvious reasons (being it's
> main goal) has. I guess it's akin to gentoo hardened fixing/preferring
> their glibc and mozilla not making their binaries pax compatible
The bug in my opinion is rely into noexec mount option as a security option
since you don't need it to launch untrusted code, just a perl/python
interpreter is needed.
[-- Attachment #2: Type: text/html, Size: 4138 bytes --]
next prev parent reply other threads:[~2011-12-12 15:24 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-12-10 20:17 [gentoo-hardened] New Server, considering hardened, need pointers to tfm Tanstaafl
2011-12-10 20:52 ` Matthew Thode
2011-12-11 10:18 ` Sven Vermeulen
2011-12-11 12:20 ` Alex Efros
2011-12-11 14:25 ` Sven Vermeulen
2011-12-11 14:53 ` Alex Efros
2011-12-11 16:49 ` Matthew Thode
2011-12-11 20:01 ` Hilco Wijbenga
2011-12-11 20:08 ` Kevin Chadwick
2011-12-12 11:56 ` Anthony G. Basile
2011-12-12 13:38 ` Kevin Chadwick
2011-12-12 14:08 ` Kevin Chadwick
2011-12-12 15:23 ` Javier Juan Martínez Cabezón [this message]
2011-12-12 16:44 ` Kevin Chadwick
2011-12-12 17:38 ` Javier Juan Martínez Cabezón
2011-12-12 18:41 ` Kevin Chadwick
2011-12-12 19:44 ` Javier Juan Martínez Cabezón
2011-12-12 20:19 ` Kevin Chadwick
2011-12-12 21:04 ` Javier Juan Martínez Cabezón
2011-12-12 22:08 ` Kevin Chadwick
2011-12-13 21:20 ` Javier Juan Martínez Cabezón
2011-12-14 11:05 ` Kevin Chadwick
2011-12-14 15:27 ` Javier Juan Martínez Cabezón
2011-12-14 15:55 ` Alex Efros
2011-12-14 16:28 ` Javier Juan Martínez Cabezón
2011-12-14 16:42 ` Kevin Chadwick
2011-12-14 18:06 ` Javier Juan Martínez Cabezón
2011-12-14 19:45 ` Kevin Chadwick
2011-12-14 3:18 ` Peter Volkov
2011-12-14 3:31 ` Peter Volkov
2011-12-11 20:30 ` Kevin Chadwick
2011-12-11 23:00 ` Matthew Finkel
2011-12-12 11:34 ` Kevin Chadwick
2011-12-12 11:59 ` Anthony G. Basile
2011-12-12 13:14 ` Kevin Chadwick
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='CAD98N_Hgm-MZCs2kTOF3zwNFfbcXba8E=Gvse=r0KGzc0puQGQ@mail.gmail.com' \
--to=tazok.id0@gmail.com \
--cc=gentoo-hardened@lists.gentoo.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox