In <200002200217.e1K2HZ216763@sleipnir.valparaiso.cl> Horst von Brand (vonbrand@sleipnir.valparaiso.cl) wrote:
HB> "Khimenko Victor" <khim@sch57.msk.ru> said:
HB> [...]
>> IMNSHO trusted mode or untrusted mode should be filesystem flag: in trusted
>> mode LOTS of programs should be configured differently. Perhaps mount option
>> will be enough. It's NOT system-wide issue, rather filesystem-wide (kernel
>> works in trusted mode even now (modulo things like mtrr not yet converted to
>> capabilities), just exec part work in non-trusted mode...
HB> I fail to see the connection between filesystem and proceses being able (or
HB> not) to bind to a low port, for instance. OK, so if your httpd resides on
HB> FAT, it has no capabilities and won't work at all.
No. It WILL work. It will inherit needed capabilities from it's owner. But
yes, now I found that quite a few other things should be changed in "trusted
Linux" (for example now apache start with UID=0 so it has all capabilities and
then with change of UID it'll drop all capabilities; in trusted system even
with change of UID capabilities will retain: UID==0 is not special in "trusted
Linux"). So system-wide option looks unavoidable :-(( Perhaps it should be
compile-time option even: daemons like apache and bind should be changed
significally to work in "trusted Linux" so there are no point in allowing to
swicth between trusted/non trusted more "on the fly".
HB> Big deal. OTOH, a mount flag in the vein of suid or dev is mandatory to
HB> ensure nobody smuggles in a capable binary from elsewhere by mounting a
HB> floppy...
HB> But AFAIKS capabilities is a systemwide decision. And even if it wasn't,
HB> binding this to the specific filesystem (or mount flags) is extra
HB> complexity, both in-kernel and for the sysadmin. Complexity precisely in
HB> the areas where you don't want any of it. No dice.
Agree. I think that even ability to switch between "trusted" and non-"trusted"
modes in run-time is overkill. Changes in system behaviour is too radical...
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Wed Feb 23 2000 - 21:00:25 EST