1 |
On Mon, 12 Dec 2011 16:23:21 +0100 |
2 |
Javier Juan Martínez Cabezón wrote: |
3 |
|
4 |
> > It's very bad idea to use sudo with scripts, in openbsd and everywhere. |
5 |
> There are a lot of documentation about this question in the web. |
6 |
> |
7 |
|
8 |
Well actually that depends it is usually worse to run a script with sudo |
9 |
but it can be worse to allow all commands within a script to be run by |
10 |
sudo. I don't put /bin/sh script in sudoers and I am careful which |
11 |
commands I put in sudoers. Please ellaborate. |
12 |
|
13 |
> |
14 |
> > Another thing that I try to do as a better method of TPE which is a |
15 |
> > breeze on OpenBSD and sometimes I find myself working against Linux |
16 |
> > developersน is to make it so that any writeable area of the filesystem |
17 |
> > is mounted noexec and mounts have the least priviledges required. |
18 |
> |
19 |
> The TPE in openbsd relies in the trustness of root, trusted is only |
20 |
> feasible if nobody could reach root account (and daemons and suid binaries |
21 |
> can still reach it in openbsd). Until openbsd doesn't implement mandatory |
22 |
> controls and privilege separation (a.k.a posix capabilities) TPE will never |
23 |
> be trusted under him . |
24 |
> |
25 |
|
26 |
Actually I was talking about TPE in Linux not being potentially as |
27 |
effective as noexec. |
28 |
|
29 |
> Other problem is script interpretation, you don't need any exec mounted |
30 |
> partition to launch a exploit, just a simple perl myhorribleexploit.pl does |
31 |
> it. |
32 |
> |
33 |
|
34 |
You still can't execve and I believe noexec on Linux now prevents that? |
35 |
|
36 |
|
37 |
> In linux you can check under rbac if a script to get interpreted is trusted |
38 |
> or not. |
39 |
> |
40 |
> |
41 |
> > I'm in the process of attempting to complete this on Linux rather than |
42 |
> > just /home etc. but on OpenBSD and the plan for single user linux |
43 |
> > systems is to remount for updates, which is done in a controlled |
44 |
> > fashion. |
45 |
> |
46 |
> Again, What is exactly controlled fashion?. It gets never controlled |
47 |
> because EXEC mount privilege is not needed to launch exploits and for this |
48 |
> reason make TPE useless. |
49 |
> |
50 |
|
51 |
Environment and monitoring at the time of updates and no dangerous |
52 |
actions like web browsing etc. etc. whilst the system is writable. |
53 |
|
54 |
> > but I probably should have just made them single user/auto-login. Bigger |
55 |
> > problems on OpenBSD servers (no devfs) are ttys for multi-user systems |
56 |
> > or multiple ssh users needing tty permission changes, otherwise only |
57 |
> > sftp works for all other users, which could be a feature for |
58 |
> > me atleast ;-). Originally I was going to try mounting /dev seperately |
59 |
> > but the book Absolute OpenBSD Unix for the practical paranoid said |
60 |
> > you couldn't, I guess it would need to be built into the kernel to boot. |
61 |
> |
62 |
> > There's also secure knocking that runs commands that may not need ttys |
63 |
> > but I think they have to be pre-ordained, but maybe not. |
64 |
> |
65 |
> If I remember correctly in openbsd exists too TIOCSTI and TIOCCONS ioctls, |
66 |
> one allows root to send commands to user tty (hijacking) and the other one |
67 |
> to spy it, how did you control under openbsd without mandatory controls? |
68 |
> |
69 |
|
70 |
An attacker is far less likely to get root on OpenBSD in the first |
71 |
place but I am not trying to compare the two systems here. I could |
72 |
reply with kernel attacks bypassing RBAC where execve would be |
73 |
helpful but I don't want merits of the two being turned into one |
74 |
of the many heated and pointless prevention versus protection debates. |
75 |
We choose our poisons and the right cocktail for each application. I |
76 |
also don't want to diverge so much from the ops original question which |
77 |
may preclude OpenBSD?. |
78 |
|
79 |
|
80 |
> > Starting with the actual bug, on OpenBSD everything is off untill you |
81 |
> > enable it like arch linux but their hotplugd allows you to easily edit |
82 |
> > the commands and so mount options. Of course their are things like |
83 |
> > devmon for Linux but the real issue was if a security policy tried to |
84 |
> > stop introduction of executable code by users and then someone used the |
85 |
> > install scripts and set up say ubuntu with udev by default then a user |
86 |
> > could make a directory owned by root on an ext2 usb possibly name |
87 |
> > it .exe and then execute their program violating the security policy |
88 |
> > and possibly without the admins realising, it's that not caring about |
89 |
> > security while developing that OpenBSD for obvious reasons (being it's |
90 |
> > main goal) has. I guess it's akin to gentoo hardened fixing/preferring |
91 |
> > their glibc and mozilla not making their binaries pax compatible |
92 |
> |
93 |
> The bug in my opinion is rely into noexec mount option as a security option |
94 |
> since you don't need it to launch untrusted code, just a perl/python |
95 |
> interpreter is needed. |
96 |
|
97 |
We disagree and if you look hard enough this was the reason the /tmp |
98 |
bug was dismissed and has now been found to have been wrongfully |
99 |
dismissed, you can't deny it hardens a system to some degree. It's quite |
100 |
possible that you don't need to have perl or python installed. Though |
101 |
OpenBSD does use perl quite extensively but also like hardening suid, |
102 |
you could still restrict it's execution to groups. I'd also like to see |
103 |
you run an unauthorised and buggy Windows program through perl that |
104 |
could even listen to the network. (wine maybe authorised only for a set |
105 |
task due to user or business demands) |
106 |
|
107 |
Personally I see RBAC as a means of making it far more difficult to get |
108 |
root. Once someone has root there is no way I'd rely on RBAC to defend |
109 |
the memory, though we can always hope an attacker gives up on the extra |
110 |
layer in our defences, which was the main point. More is better (DID). |