1 |
2011/12/12 Kevin Chadwick <ma1l1ists@××××××××.uk> |
2 |
> |
3 |
> On Mon, 12 Dec 2011 16:23:21 +0100 |
4 |
> Javier Juan Martínez Cabezón wrote: |
5 |
> |
6 |
> |
7 |
> |
8 |
> Actually I was talking about TPE in Linux not being potentially as |
9 |
> effective as noexec. |
10 |
> |
11 |
> |
12 |
> You still can't execve and I believe noexec on Linux now prevents that? |
13 |
> |
14 |
|
15 |
|
16 |
I repeat, you don't need execve to launch untrusted code. When you do |
17 |
"perl /tmp/somenastyscript", the script works even if you mounted as |
18 |
noexec /tmp. This happens because the execve is only launch in |
19 |
/bin/perl that "usually" has exec granted, in mynastyscript you only |
20 |
just need read privileges granted in noexec. |
21 |
|
22 |
None TPE without mandatory access control is effective, noexec is as |
23 |
useless as TPE against script interpretation. The main difference is |
24 |
that in linux you can implement a fully secure TPE, not under openbsd |
25 |
since it lacks of rbac approachs. |
26 |
|
27 |
Only a rbac can assure TPE restricting script interpretation as this: |
28 |
|
29 |
perl execve ----->run under role perl.----->check-------- if script |
30 |
marked trusted ----> change to user role and do what you have to do |
31 |
--------> if script |
32 |
untrusted (didn't mark as trusted)---> don't permit read and as result |
33 |
don't make transition.. |
34 |
|
35 |
Since role perl has only read privileges against trusted scripts and |
36 |
nothing else, TPE is secure because every untrusted code is prevented |
37 |
from execution. |
38 |
|
39 |
Under rsbac, execution is controlled under EXECUTE privilege with |
40 |
execve and related calls and with MAP_EXEC for library mappings., TPE |
41 |
is just a less approach under it because nothing has EXECUTE |
42 |
privileges if they are not /bin /sbin or /lib directories is a result |
43 |
of the less priviledge approach of rbac. |
44 |
|
45 |
> Environment and monitoring at the time of updates and no dangerous |
46 |
> actions like web browsing etc. etc. whilst the system is writable. |
47 |
|
48 |
a bug in package software which privileges would grant to an attacker |
49 |
with a crafted package exploiting a bug?, and if a privilege daemon is |
50 |
running? |
51 |
|
52 |
Your main problem is that you consider root trusted, and is not. |
53 |
|
54 |
> |
55 |
> An attacker is far less likely to get root on OpenBSD in the first |
56 |
> place but I am not trying to compare the two systems here. I could |
57 |
> reply with kernel attacks bypassing RBAC where execve would be |
58 |
> helpful but I don't want merits of the two being turned into one |
59 |
> of the many heated and pointless prevention versus protection debates. |
60 |
> We choose our poisons and the right cocktail for each application. I |
61 |
> also don't want to diverge so much from the ops original question which |
62 |
> may preclude OpenBSD?. |
63 |
|
64 |
who says that?, I'm sure that even with root account under my system |
65 |
you don't get privileges at all, since root has not privileges. This |
66 |
is the reason because a gnu/linux system could reach to B1 orange book |
67 |
security level and openbsd to a simply C2, so linux can reach a |
68 |
trusted status that openbsd no. |
69 |
|
70 |
Openbsd only does a check, source code is full of if UID!=0 to everything. |
71 |
|
72 |
It's a terrible error to think that openbsd has no errors, because |
73 |
they have, it's wise to be prepared against bugs as MAC solutions |
74 |
offers, it's of idiots to think that my software is perfect and free |
75 |
of bugs and to think that they don't need MAC. |
76 |
|
77 |
|
78 |
> We disagree and if you look hard enough this was the reason the /tmp |
79 |
> bug was dismissed and has now been found to have been wrongfully |
80 |
> dismissed, you can't deny it hardens a system to some degree. It's quite |
81 |
> possible that you don't need to have perl or python installed. Though |
82 |
> OpenBSD does use perl quite extensively but also like hardening suid, |
83 |
> you could still restrict it's execution to groups. I'd also like to see |
84 |
> you run an unauthorised and buggy Windows program through perl that |
85 |
> could even listen to the network. (wine maybe authorised only for a set |
86 |
> task due to user or business demands) |
87 |
> |
88 |
> Personally I see RBAC as a means of making it far more difficult to get |
89 |
> root. Once someone has root there is no way I'd rely on RBAC to defend |
90 |
> the memory, though we can always hope an attacker gives up on the extra |
91 |
> layer in our defences, which was the main point. More is better (DID). |
92 |
> |
93 |
I repeat to you EXECUTE rights in a rbac system is granted just only |
94 |
to /bin and /lib directories, none to /tmp. RBAC is sufficient to |
95 |
avoid and confine this bug, you give me the reason because openbsd TPE |
96 |
is useless, perl is present and uncontrolled as in "perl |
97 |
/tmp/something". Try this it under openbsd with /tmp with noexec and |
98 |
you will see that you can launch every script you want (without exec |
99 |
calls but you dont need them to exploit vulnerabilities). |
100 |
|
101 |
In rbac you can restrict PTRACE even to root, cap_sys_ptrace controls |
102 |
it, PaX restricts the existence of PROT_EXEC PROT_WRITE simultaneously |
103 |
in memory. Root under rbac neither can't mmap /dev/mem because he has |
104 |
CAP_SYS_RAWIO removed, neither /dev/ports to I/O. Get realize that |
105 |
root in rbac is not more than a simple user. Accessing to devices are |
106 |
also fully controled and labeled according a B2 security level. If you |
107 |
have modules interface they are controlled by CAP_SYS_MODULE that |
108 |
could be revoked to root. |
109 |
|
110 |
Suid to other uids are fully controlled, so nothing of suid(privuser) |
111 |
to root. CAP_SYS_SUID check AND RBAC check, so both should be granted |
112 |
to work. |
113 |
|
114 |
Now please tell me how under this circunstances could root to make nothing. |