Remote Exec etc..

[Pavel Kankovsky]

On Fri, 9 Oct 1998, Petr Snajdr wrote:

[licence ssh]
> Premyslel jsem jak svuj pozadavek na licenci nejlepe formulovat.
> Co treba tak, aby takovy sw. mohl byt soucasti Debianu a 
> nebyl zarazen do non-free? :-)

Debianovska pravidla ta licence rozhodne nesplnuje.

> > Mame si pripravit hasici pristroj? :)
> 
> To nevim :-), poznamenal jsem to spis jen tak k tomu TCL.
> Nicmene (tradicne naivni) otazka: proc? :-)

Tim jsem myslel jestli bude flamewar TCP vs Python vs kdovico. :)

> 	Trochu me stve, ze bezpecnost si resi kazda
> aplikace sama (pokud mozno s root pravy). A vubec, ze 

To mne taky.

> i veci na ktere root prava nejsou treba se delaji
> nebo standardne musi delat s root pravy.

Zvlast ty, ve kterych je neco jako:

  if (getuid() != 0) {
    fprintf(stderr, "je nam lito\n");
    exit(1);
  }

(nechci jmenovat zadny sendmail)

> BTW: Zkousel jste nekdo v posledni dobe Linux privs?

Tzv. capabilities (*) budou v 2.2. Audit, ACLka a set-cap (neco jako
set-uid, ale pro capabilities), pokud vim, nikoli (posledni dve z toho
duvodu, ze pozaduji upravu filesystemu). Jaderni experti mozna budou vedet
vic.

BTW: jeste existuje GSS-API, co mj. resi otazku vzdalene identifikace,
autorizace a autentizace a taktez ochranu prenasenych dat. Na Linuxu by
mela byt pouzitelna implementace ze Sesame (neco jako Kerberos the Next
Generation).


--Pavel Kankovsky aka Peak  [ Boycott Microsoft--http://www.vcnet.com/bms ]
"You can't be truly paranoid unless you're sure they have already got you."


(*) capabilities je v tomto kontextu strasne zmatecne jmeno, protoze
    je to spis neco jako privilegia ve VMS, nez capabilities v KeyKOSu
    nebo EROSu