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.
