| 1 |
I don't care so much about this security issue because assuming that |
| 2 |
you are using a function in a scope shared by the rc scripts and |
| 3 |
haven't hard coded the way to read such arguments in every rc-script, |
| 4 |
it would be trivial to add some security measures later on. |
| 5 |
|
| 6 |
However from a alternative platform/architecture point of view I have |
| 7 |
to note that at least a kernel dependent strategy might be needed here. |
| 8 |
I wonder whether kernels such as for instance the hurd pass arguments |
| 9 |
the same way as a linux kernel and whether newer linux kernel releases |
| 10 |
might not change this process, thus requiring different rc scripts for |
| 11 |
each kernel while only a different runtime strategy is needed. |
| 12 |
Currently not an urgent issue, but we'll have to take this into |
| 13 |
account. |
| 14 |
|
| 15 |
Pieter |
| 16 |
|
| 17 |
On 17 Jan 2004, at 18:06, Brad House wrote: |
| 18 |
|
| 19 |
> no, the rcscripts must now parse the kernel commandline opts |
| 20 |
> to get a few options. There's really not many other ways to |
| 21 |
> do it. Besides you just proved by your statement that someone |
| 22 |
> could instead pass init=/bin/sh and override any sort of |
| 23 |
> init process, so trying to make the 'cdroot' option secure |
| 24 |
> is obsurd, as there's 10 million other ways to get in if you |
| 25 |
> have direct access to the computer. |
| 26 |
> |
| 27 |
> -Brad |
| 28 |
|
| 29 |
|
| 30 |
-- |
| 31 |
gentoo-releng@g.o mailing list |
Archives