1 |
About this*: |
2 |
|
3 |
|
4 |
> What for after the main install, password changes (I use scripts |
5 |
> allowed via sudo for that and monitor mounts globally but the monitoring |
6 |
> could be improved like grsecs offering), some programs require it during |
7 |
> install but not many, none on my OpenBSD mail and web servers. |
8 |
|
9 |
* |
10 |
|
11 |
> |
12 |
> It's very bad idea to use sudo with scripts, in openbsd and everywhere. |
13 |
There are a lot of documentation about this question in the web. |
14 |
|
15 |
|
16 |
> Another thing that I try to do as a better method of TPE which is a |
17 |
> breeze on OpenBSD and sometimes I find myself working against Linux |
18 |
> developersน is to make it so that any writeable area of the filesystem |
19 |
> is mounted noexec and mounts have the least priviledges required. |
20 |
|
21 |
The TPE in openbsd relies in the trustness of root, trusted is only |
22 |
feasible if nobody could reach root account (and daemons and suid binaries |
23 |
can still reach it in openbsd). Until openbsd doesn't implement mandatory |
24 |
controls and privilege separation (a.k.a posix capabilities) TPE will never |
25 |
be trusted under him . |
26 |
|
27 |
Other problem is script interpretation, you don't need any exec mounted |
28 |
partition to launch a exploit, just a simple perl myhorribleexploit.pl does |
29 |
it. |
30 |
|
31 |
In linux you can check under rbac if a script to get interpreted is trusted |
32 |
or not. |
33 |
|
34 |
|
35 |
> I'm in the process of attempting to complete this on Linux rather than |
36 |
> just /home etc. but on OpenBSD and the plan for single user linux |
37 |
> systems is to remount for updates, which is done in a controlled |
38 |
> fashion. |
39 |
|
40 |
Again, What is exactly controlled fashion?. It gets never controlled |
41 |
because EXEC mount privilege is not needed to launch exploits and for this |
42 |
reason make TPE useless. |
43 |
|
44 |
> but I probably should have just made them single user/auto-login. Bigger |
45 |
> problems on OpenBSD servers (no devfs) are ttys for multi-user systems |
46 |
> or multiple ssh users needing tty permission changes, otherwise only |
47 |
> sftp works for all other users, which could be a feature for |
48 |
> me atleast ;-). Originally I was going to try mounting /dev seperately |
49 |
> but the book Absolute OpenBSD Unix for the practical paranoid said |
50 |
> you couldn't, I guess it would need to be built into the kernel to boot. |
51 |
|
52 |
> There's also secure knocking that runs commands that may not need ttys |
53 |
> but I think they have to be pre-ordained, but maybe not. |
54 |
|
55 |
If I remember correctly in openbsd exists too TIOCSTI and TIOCCONS ioctls, |
56 |
one allows root to send commands to user tty (hijacking) and the other one |
57 |
to spy it, how did you control under openbsd without mandatory controls? |
58 |
|
59 |
> Starting with the actual bug, on OpenBSD everything is off untill you |
60 |
> enable it like arch linux but their hotplugd allows you to easily edit |
61 |
> the commands and so mount options. Of course their are things like |
62 |
> devmon for Linux but the real issue was if a security policy tried to |
63 |
> stop introduction of executable code by users and then someone used the |
64 |
> install scripts and set up say ubuntu with udev by default then a user |
65 |
> could make a directory owned by root on an ext2 usb possibly name |
66 |
> it .exe and then execute their program violating the security policy |
67 |
> and possibly without the admins realising, it's that not caring about |
68 |
> security while developing that OpenBSD for obvious reasons (being it's |
69 |
> main goal) has. I guess it's akin to gentoo hardened fixing/preferring |
70 |
> their glibc and mozilla not making their binaries pax compatible |
71 |
|
72 |
The bug in my opinion is rely into noexec mount option as a security option |
73 |
since you don't need it to launch untrusted code, just a perl/python |
74 |
interpreter is needed. |