On Mon, 12 Dec 2011 16:23:21 +0100
Javier Juan Martínez Cabezón wrote:

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

Well actually that depends it is usually worse to run a script with sudo
but it can be worse to allow all commands within a script to be run by
sudo. I don't put /bin/sh script in sudoers and I am careful which
commands I put in sudoers. Please ellaborate.

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

Actually I was talking about TPE in Linux not being potentially as
effective as noexec.
 
> 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.
> 

You still can't execve and I believe noexec on Linux now prevents that?


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

Environment and monitoring at the time of updates and no dangerous
actions like web browsing etc. etc. whilst the system is writable.

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

An attacker is far less likely to get root on OpenBSD in the first
place but I am not trying to compare the two systems here. I could
reply with kernel attacks bypassing RBAC where execve would be
helpful but I don't want merits of the two being turned into one
of the many heated and pointless prevention versus protection debates.
We choose our poisons and the right cocktail for each application. I
also don't want to diverge so much from the ops original question which
may preclude OpenBSD?.


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

We disagree and if you look hard enough this was the reason the /tmp
bug was dismissed and has now been found to have been wrongfully
dismissed, you can't deny it hardens a system to some degree. It's quite
possible that you don't need to have perl or python installed. Though
OpenBSD does use perl quite extensively but also like hardening suid,
you could still restrict it's execution to groups. I'd also like to see
you run an unauthorised and buggy Windows program through perl that
could even listen to the network. (wine maybe authorised only for a set
task due to user or business demands)

Personally I see RBAC as a means of making it far more difficult to get
root. Once someone has root there is no way I'd rely on RBAC to defend
the memory, though we can always hope an attacker gives up on the extra
layer in our defences, which was the main point. More is better (DID).