Date: Sun, 29 Aug 1999 16:03:14 +0400 (MSD) From: CyberPsychotic <fygrave@tigerteam.net> To: EuroHack ML <eurohack@bofh.kyrnet.kg> Cc: freebsd-hackers@freebsd.org Subject: Re: [EuroHaCk] re + init + securelevel-nonsense Message-ID: <Pine.GSO.4.05.9908291556280.2714-100000@ns.kyrnet.kg> In-Reply-To: <199908271610.SAA13906@dione.ids.pl>
next in thread | previous in thread | raw e-mail | index | archive | help
~
~ >if anyone ever played with shells, maybe you'd like to have a look on
~ >restricted shell, I did for a couple of hours. the only thing I haven't
~ So break out via 'exec bash' ;-)
eh?;-) sh on OpenBSD (at least) has quite nice feature to disable exec'ing
any stuff which has path specified if shell name matches *r*sh pattern(i.g.
it would run passwd but not /usr/bin/passwd etc) so by setting up safe path
variable (which is done in my shell) and copying only user-safe proggies
into the place would be safe enuff.
~ >figured, is how, when spawned process is suspended, I should make shell
~ >fell like it received SIGCONT signal.. oh, well, I need to get to my unice
~ >bible back again.. :)
~ APUE? ;-)
yep. :)
~ Some1 an idea why FreeBSD 3.1. fails to set seclevel back to 0
~ when sending init signal 15 to get to singleuser-mode?
~
might be bug in code. What would freebsd-hackers say?;-)
~ In openBSD it works fine, but OpenBSD sets seclevel to 1 while boot.
~ On F*BSD i set it by hand.
~ Ahhh...sending 25 times a SIGSYS to init gives kernel-panic. No wonder...
eh.. heh :-)
~ + delete /usr/src/sys
~ + disable LKM's
~ + disable bpf
~ + set seclevel to 3
~ + set up proper fw
~ + disable all accounts and run only httpd or what you need
~
~ }|-)
:-) okay. now that's gotta be beginning of BSD security howto.. ;-)
~ It would be absolutely no fun to go to this machine.
securelevel 2:
Highly secure mode - same as secure mode, plus disks are always
read-only whether mounted or not and the settimeofday(2) system
call can only advance the time. This level precludes tampering
with filesystems by unmounting them, but also inhibits running
newfs(8) while the system is multi-user. Because the clock cannot
be set back in time, malicious users who have gained root privi-
leges are unable to change a file's ctime.
uhum.. sounds good ;-)
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.GSO.4.05.9908291556280.2714-100000>