Pozdrawiam
> Jak w temacie potrzebuje skompilowaćskrypty
No to powodzenia.
Może ktoś zgadnie o co Ci chodzi...
./KonMan
--
Feel free
to jabber me.
w jakim celu?
Tomek
>> Jak w temacie potrzebuje skompilowaćskrypty
>
> No to powodzenia.
> Może ktoś zgadnie o co Ci chodzi...
A którego słowa nie zrozumiałeś? Bo ja wiem o co mu chodzi co nie zmienia
faktu, że nie wiem nawet czy istnieje jakieś oprogramowanie kompilujące
skrypty.
pozdr,
fEnIo
--
,''`. Bartosz Fenski | mailto:fe...@debian.org | pgp:0x13fefc40 | irc:fEnIo
: :' : 32-050 Skawina - Glowackiego 3/15 - w. malopolskie - Poland
`. `' phone:+48602383548 | proud Debian maintainer and user
`- http://skawina.eu.org | jid:fe...@jabber.org | rlu:172001
a potrzeba mi poto zeby zabezpieczyc zrodla skryptow
daj znać jak osiągniesz cel...
KubiS
Nie chodzi Ci o "sh skrypt"?
Jeśli chodzi Ci o kompilowanie do kodu binarnego to raczej nie - szkoda
czasu i zachodu, by taki kompilator napisać.
Jeśli ma być wydajne i/lub zamknięte - przepisz do C/C++.
Pozdrawiam.
--
Linux user: #376500 (patrz http://counter.li.org/)
istniec to chyba nie istnieje, w pelnym zrozumieniu slowa kompilator
(+zadziala szybciej).
bo jakze mialoby to skompilowac takie cos:
#!/bin/bash
komenda_1
komenda_2
komenda_3
aczkolwiek przy takim czyms mozna sie juz zastanawiac nad sensownoscia
kompilowania:
#!/bin/bash
komenda_1 user haslo
komenda_2 user haslo
inny user moglby podejzec haslo korzystajac ze zwyklego ps...
wtedy z pomoca przychodzi shc:
http://www.linuxsecurity.com/content/view/117920/49/
Tomek
Pozdrawiam
--
Jakub Panachida
>> A którego słowa nie zrozumiałeś? Bo ja wiem o co mu chodzi co nie zmienia
>> faktu, że nie wiem nawet czy istnieje jakieś oprogramowanie kompilujące
>> skrypty.
>
> istniec to chyba nie istnieje, w pelnym zrozumieniu slowa kompilator
> (+zadziala szybciej).
>
> bo jakze mialoby to skompilowac takie cos:
>
> #!/bin/bash
> komenda_1
> komenda_2
> komenda_3
#include <stdlib.h>
int main(void) {
system("komenda_1");
system("komenda_2");
system("komenda_3");
}
;)
> aczkolwiek przy takim czyms mozna sie juz zastanawiac nad sensownoscia
> kompilowania:
>
> #!/bin/bash
> komenda_1 user haslo
> komenda_2 user haslo
To raczej średnio bezpieczny sposób przetrzymywania hasła.
> inny user moglby podejzec haslo korzystajac ze zwyklego ps...
>
> wtedy z pomoca przychodzi shc:
>
> http://www.linuxsecurity.com/content/view/117920/49/
W przypadku zwykłej kompilacji podejrzy sobie w binarce.
No chyba, że shc coś czaruje, ale sprawdzać mi się nie chce.
--
Jakub Panachida
> Owszem istnieje np shc :) ale przy wiekszych skryptach ma problemy
>
> a potrzeba mi poto zeby zabezpieczyc zrodla skryptow
A nie wystarczy opatrzyć odpowiednią licencją?
--
http://www.piotr.dembiński.prv.pl
Nie podejrzy, jeśli odbierzesz mu prawo odczytu binarki.
--
Pozdrawiam,
Lech Lorens - lp.pw@snerol_hcel
>> W przypadku zwykłej kompilacji podejrzy sobie w binarce.
>
> Nie podejrzy, jeśli odbierzesz mu prawo odczytu binarki.
>
Podejrzy. Strace ./binarka i już mamy hasło.
--
Maciej "Fiedzia" Dziardziel (fiedzia (at) fiedzia (dot) prv (dot) pl)
www.fiedzia.prv.pl
Dodam że:
1. UPX potrafi pakować skrypty shella (w pewnym sensie szyfruje)
2. Pod DOS-em jest kompilator plików BAT
> Lech Lorens wrote:
>
>>> W przypadku zwykłej kompilacji podejrzy sobie w binarce.
>>
>> Nie podejrzy, jeśli odbierzesz mu prawo odczytu binarki.
>>
>
> Podejrzy. Strace ./binarka i już mamy hasło.
>
No chyba że odbiezesz prawo do wykonywania kernelowej funkcji ptrace.
Tomek
>>>> W przypadku zwykłej kompilacji podejrzy sobie w binarce.
>>> Nie podejrzy, jeśli odbierzesz mu prawo odczytu binarki.
>> Podejrzy. Strace ./binarka i już mamy hasło.
> No chyba że odbiezesz prawo do wykonywania kernelowej funkcji ptrace.
Jeśli ma się takie możliwości to równie dobrze można się całkiem pozbyć
strace i nie pozwolić userowi przywlec nic z zewnątrz.
Jeśli ktoś chce i umie tak strasznie kombinować, to kompilator skryptów mu
się i tak nie przyda (bo sam poradzi sobie lepiej).
Jeśli ktoś chce się chronić przed strace, to chyba pomóc może zwykłe
wypchnięcie newralgicznych fragmentów kodu do biblioteki *.so? To chyba
powstrzymałoby większość amatorów...
Jak by nie patrzeć sprawa jest mocno akademicka, IMHO.
Kompilator skryptów jakimś strasznie skutecznym zabezpieczeniem nie jest,
ale odsiewa większość ciekawskich i to chyba wystarcza...
--
.°.°.°.°.°.°.: http://dobremiasto.net/~hoppke/ :.°.°.°.°.°.°.
A samochod na noc zamykasz czy zostawiasz kartke?
--
Slawomir Sidor N 51 58.1385 E020 09.1966
Moze jakis obfuscator by mu wystarczyl. Czy jest jakis - nie sprawdzalem.
Nie bylo takiej potrzeby.
Artur
--
[ Artur M. Piwko : Pipen : AMP29-RIPE : RLU:100918 : From == Trap! : SIG:214B ]
[ 09:51:22 user up 10601 days, 21:46, 1 user, load average: 0.06, 0.06, 0.06 ]
God: Darwin's chief rival.
>> A nie wystarczy opatrzyć odpowiednią licencją?
>
> A samochod na noc zamykasz czy zostawiasz kartke?
Dobre porównanie. Przytoczę inne.
Widziałem kiedyś film dokumentalny, w którym autor porównywał
zwyczaje panujące w Kanadzie i USA. Większość obywateli
kanadyjskich nie zamyka w ogóle drzwi na klucz, natomiast
w USA -- praktycznie wszyscy.
--
http://www.piotr.dembiński.prv.pl
czy nie chodzi o film "bowling for columbine"? :)
Tomek
Tak, to ten film.
--
http://www.piotr.dembiński.prv.pl
> Lech Lorens wrote:
>
>>> W przypadku zwykłej kompilacji podejrzy sobie w binarce.
>>
>> Nie podejrzy, jeśli odbierzesz mu prawo odczytu binarki.
>>
>
> Podejrzy. Strace ./binarka i już mamy hasło.
>
Nie. shc ma możliwość zablokowania strace. Poza tym, żeby zabezpieczyć sie
przed podejrzeniem ps -whatever wystarczy pierwsze, żeby pierwsze linijki
wyglądały tak:
#!/bin/bash
###[80 haszy]
[x 40 linii]
i wsjo.
pozdrawiam,
--
Jaroslaw Zachwieja
GPG/PGP key at http://pgp.mit.edu
foo1 w adresie to podpucha :)
>> Podejrzy. Strace ./binarka i już mamy hasło.
>>
>
> Nie. shc ma możliwość zablokowania strace.
No to sobie odczytam parametry procesów z /proc.
> Poza tym, żeby zabezpieczyć sie
> przed podejrzeniem ps -whatever wystarczy pierwsze, żeby pierwsze linijki
> wyglądały tak:
>
> #!/bin/bash
>
> ###[80 haszy]
> [x 40 linii]
??? I to niby spowoduje że parametry procesów potomnych nie będą dostępne
przez /proc?
--
Maciej "Fiedzia" Dziardziel (fiedzia (at) fiedzia (dot) prv (dot) pl)
www.fiedzia.prv.pl
DOS is Unix's retarded younger brother.
> Jaroslaw Zachwieja wrote:
>
>>> Podejrzy. Strace ./binarka i już mamy hasło.
>>>
>>
>> Nie. shc ma możliwość zablokowania strace.
>
> No to sobie odczytam parametry procesów z /proc.
>
>> Poza tym, żeby zabezpieczyć sie
>> przed podejrzeniem ps -whatever wystarczy pierwsze, żeby pierwsze linijki
>> wyglądały tak:
>>
>> #!/bin/bash
>>
>> ###[80 haszy]
>> [x 40 linii]
>
> ??? I to niby spowoduje że parametry procesów potomnych nie będą dostępne
> przez /proc?
Sam zobacz. ZTCW jest limit na długość polecenia.
Pozdrawiam,
Bzdura. shc tylko na początku sprawdza czy nie jest uruchamiane spod
strace. Spokojnie można się później do procesu "dopiąć".
--
Kruk@ -\ | Microsoft Office 2000: Zapominasz o słowach
}-> epsilon.eu.org | "tego nie da się zrobić"
http:// -/ |
|
>>> Poza tym, żeby zabezpieczyć sie
>>> przed podejrzeniem ps -whatever wystarczy pierwsze, żeby pierwsze
>>> linijki wyglądały tak:
>>>
>>> #!/bin/bash
>>>
>>> ###[80 haszy]
>>> [x 40 linii]
>>
>> ??? I to niby spowoduje że parametry procesów potomnych nie będą dostępne
>> przez /proc?
>
> Sam zobacz. ZTCW jest limit na długość polecenia.
Z ciekawości sprawdziłem ( a nuż o czymś nie wiem) i nadal niczego dziwnego
w tym nie widzę. # to komentarz i shell go zignoruje, choćby tych liniii
było i 40 tysięcy. Wpływu na kernel ani shella żadnego nie zauważyłem.
Limit długości polecenia pewnie jakiś jest (acz man execve nie mówi jaki ani
nigdzie w tym temacie nie odsyła), ale to daje tylko tyle, że za długie
polecenie nie zostanie wykonane (zwrócony zostanie E2BIG). Mówiąc krótko -
jeżeli zamierzasz pozwolić na uruchomienie czegokolwiek w niezaufanym
środowisku, to zabezpieczyć się przed podejrzeniem parametrów uruchamianych
procesów nie ma jak. A w przeciwnym razie żadne sztuczki z kompilowanie
skryptu nie są potrzebne, bo można to poprawnie i bezpiecznie zrobić bez
stosowania półśrodków.
--
Maciej "Fiedzia" Dziardziel (fiedzia (at) fiedzia (dot) prv (dot) pl)
www.fiedzia.prv.pl
Friends may come and go, but enemies accumulate.