Re: Useful tools missing from /rescue
On 2007-09-02 11:18, Tim Kientzle <[EMAIL PROTECTED]> wrote:
> Yar Tikhiy wrote:
>> In addition, there are chflags and chmod in /rescue, but there's no
>> chown in it, so the toolset is a bit incomplete.
>
> Oh, my. chown was definitely an oversight. That
> should have been in there.
Probably because chown is a relatively big binary. If build as a static
binary here, it ends up being:
$ pwd
/home/keramida/bsd/src/usr.sbin/chown
$ make DEBUG_FLAGS='' NO_SHARED=yes all
[...]
$ ls -ld chown
-rwxrwxr-x1 keramida users - 2297013 Sep 3 03:06 chown
$ strip -s chown
$ ls -ld chown
-rwxrwxr-x1 keramida users - 550624 Sep 3 03:06 chown
$
This will get smaller when crunched, but it's still almost 4x the size
of chmod:
$ pwd
/home/keramida/bsd/src/bin/chmod
$ make DEBUG_FLAGS='' NO_SHARED=yes all
[...]
$ ls -ld chmod
-rwxrwxr-x 1 keramida users - 662678 Sep 3 03:08 chmod
$ strip -s chmod
$ ls -ld chmod
-rwxrwxr-x 1 keramida users - 165884 Sep 3 03:08 chmod
$
Running nm(1) on the binaries, I see that they have the same symbols
though:
$ nm -S chmod | awk '{print $2,$3,$4}' | sort > /tmp/symbols.chmod
$ nm -S chown | awk '{print $2,$3,$4}' | sort > /tmp/symbols.chown
$ diff -u /tmp/symbols.chmod /tmp/symbols.chown
$
Does this mean that adding chown to the already crunched binary will not
cause a lot of bloat because of symbols/functions private to chown?
- Giorgos
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Useful tools missing from /rescue
Tim Kientzle wrote: I atttempted to fit 'vi' in there, but curses is rather finicky; 'sed' would be more useful. Mined is a nice editor for this, running without curses. A statically linked, stripped binary is about 100k in size, so if crunched it would have a very small impact. cheers simon ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Useful tools missing from /rescue
Yar Tikhiy wrote: Hi all, I've had to use /rescue recently and felt lack of a few basic tools in it, namely pgrep(1), head(1), tail(1), tee(1), and a text filter, e.g., sed(1). Well, in fact most functionality of pgrep(1), head(1), tail(1), and even tee(1) can be emulated if one has sed(1), but the tools are so tiny and convenient that it's a pity not to have them all handy during hard times. In addition, there are chflags and chmod in /rescue, but there's no chown in it, so the toolset is a bit incomplete. Oh, my. chown was definitely an oversight. That should have been in there. My opinions: * head, tail, and tee are no-brainers; just do it. * sed would be a nice addition. (I atttempted to fit 'vi' in there, but curses is rather finicky; 'sed' would be more useful.) * I personally would not add pgrep/pkill because I never use them. Of course, it's hard to get worked up about 45k, so feel free to ignore the above. Cheers, Tim Kientzle ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: what happened to make world?
On Sun, 02 Sep 2007 03:49:12 -0700 [EMAIL PROTECTED] wrote: > Not every FreeBSD user is [still] a "computer enthusiast". It just so > happens that the OS at the time is the best one for many, many different > uses, such as: server, router, research workstation, 'desktop', etc. > It is basically an excellent universal tool for many > (computer_science|IT)-unrelated tasks, e.g. machine in a physics lab. For me, FreeBSD is the best platform for developers and senior support personnel to build custom solutions to those problems on. It provides a basic platform on which you can build things with minimal effort. Developers love this. > You see, it'd make me really sad to see FBSD go in the direction of > Linux one day, and be geared towards (hackish) developers. You know, I see GNU/Linux (as RMS notes, most of the userland utilities are from GNU, and they, not Linus, deserve the credit - or in this case the blame) as being much more geared towards users than developers when compared to FreeBSD. GNU/Linux distros tend to come prebuilt to solve those problems the way the distributors think they should be solved. If that happens to work for you, great - you win. Users love this. If it doesn't work for you, you have to build your own. Of course, first you have to get the GNU/Linux distro to the point where you can build your own. The prepackaged solutions wind up getting in the way all along the path. Developers hate this. FreeBSD, on the other hand, doesn't have those solutions preinstalled - you have to at least navigate the packages or ports system. Users hate this. I won't go into the differences between the packages software for FreeBSD vs. RHE, I'll just note that software installed by RHE has a habit of not working the way I need it to, and getting it to do the right thing almost always involves something disgusting, obscene or both. http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Exclusive binary files
On Sun, 2 Sep 2007 12:45:09 +0200 Joerg Sonnenberger <[EMAIL PROTECTED]> wrote: > On Sat, Sep 01, 2007 at 06:30:20PM -0400, Mike Meyer wrote: > > On Sat, 1 Sep 2007 14:27:42 -0300 "Klaus Schneider" <[EMAIL PROTECTED]> > > wrote: > > > Well, anybody know a way to make the FreeBSD run just binaries that I have > > > compiled? > > In general, it's impossible. There's no way the system can know that > > you compiled a binary. There are a number of things you could do with > > a custom kernel and toolchain to indicate that you compiled the binary > > (like Peter's changing of ELF OSABI), but that's just security through > > obscurity. If someone figures out those changes and replicates them, > > you lose. > You mean using cryptographic hashes to ensure that binaries match those > you compiled is impossible? Something like NetBSD's veriexec? Yes, that's possible, but "don't execute binaries I don't tell you are ok" is not (quite) the same thing as "don't execute binaries I compiled" or "don't execute binaries I didn't sign" or "don't execute ". There are a number of things possible that are close to what he asked for, with different strengths and weaknesses. Valid responses include listing all of them, or guessing at his requirements and providing the best solution for the guess. However, I suspect that all those solutions are a lot more painful than solving whatever issues keep him from mounting his user partition noexec, so I chose another valid response, and asked for more information about his requirements. http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Exclusive binary files
On Sun, 2 Sep 2007, Max Laier wrote: On Saturday 01 September 2007, Klaus Schneider wrote: Well, anybody know a way to make the FreeBSD run just binaries that I have compiled? For example: A hacker get a access to a shell into my server, and then it put a exploit code, but on the machine don't have a compiler, then he tries to put the compiled exploit... supose that I can't mount the users partition in "noexec" mode... Anybode knows a solution for these? IIRC csjp@ had some code to do this inside the MAC framework. Storing hashes in extended attributes and only allowing execution of signed executables ... http://perforce.freebsd.org/fileLogView.cgi?FSPC=//depot/projects/trustedbsd/mac/sys/security/mac%5fchkexec/mac%5fchkexec.c ... not sure what became of it, though. I believe he also was able to verify other things, such as shared libraries, which for modern binaries is the obvious next step given that a fair chunk of code run in many programs isn't in the main program binary. Robert N M Watson Computer Laboratory University of Cambridge ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Exclusive binary files
On Saturday 01 September 2007, Klaus Schneider wrote: > Hi. > > Well, anybody know a way to make the FreeBSD run just binaries that I > have compiled? > > For example: > A hacker get a access to a shell into my server, and then it put a > exploit code, but on the machine don't have a compiler, then he tries > to put the compiled exploit... supose that I can't mount the users > partition in "noexec" mode... > > Anybode knows a solution for these? IIRC csjp@ had some code to do this inside the MAC framework. Storing hashes in extended attributes and only allowing execution of signed executables ... http://perforce.freebsd.org/fileLogView.cgi?FSPC=//depot/projects/trustedbsd/mac/sys/security/mac%5fchkexec/mac%5fchkexec.c ... not sure what became of it, though. -- /"\ Best regards, | [EMAIL PROTECTED] \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | [EMAIL PROTECTED] / \ ASCII Ribbon Campaign | Against HTML Mail and News signature.asc Description: This is a digitally signed message part.
Re: Exclusive binary files
2007/9/2, Joerg Sonnenberger <[EMAIL PROTECTED]>: > > On Sat, Sep 01, 2007 at 06:30:20PM -0400, Mike Meyer wrote: > > On Sat, 1 Sep 2007 14:27:42 -0300 "Klaus Schneider" <[EMAIL PROTECTED]> > wrote: > > > Well, anybody know a way to make the FreeBSD run just binaries that I > have > > > compiled? > > > > In general, it's impossible. There's no way the system can know that > > you compiled a binary. There are a number of things you could do with > > a custom kernel and toolchain to indicate that you compiled the binary > > (like Peter's changing of ELF OSABI), but that's just security through > > obscurity. If someone figures out those changes and replicates them, > > you lose. > > You mean using cryptographic hashes to ensure that binaries match those > you compiled is impossible? Something like NetBSD's veriexec? > > Joerg > ___ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "[EMAIL PROTECTED]" > Yes. The alternative would be somethink like veriexec, using hashes into elf binaries... -- /* * Klaus Schneider */ ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Exclusive binary files
Joerg Sonnenberger <[EMAIL PROTECTED]> wrote: > > On Sat, Sep 01, 2007 at 06:30:20PM -0400, Mike Meyer wrote: > > On Sat, 1 Sep 2007 14:27:42 -0300 "Klaus Schneider" <[EMAIL PROTECTED]> > > wrote: > > > Well, anybody know a way to make the FreeBSD run just binaries that I have > > > compiled? > > > > In general, it's impossible. There's no way the system can know that > > you compiled a binary. There are a number of things you could do with > > a custom kernel and toolchain to indicate that you compiled the binary > > (like Peter's changing of ELF OSABI), but that's just security through > > obscurity. If someone figures out those changes and replicates them, > > you lose. > > You mean using cryptographic hashes to ensure that binaries match those > you compiled is impossible? Something like NetBSD's veriexec? Also, the situation can be actively _detected_ using something like tripwire or samhain. It'd be up to the admin to step in and stop things when a problem is detected, but at least you'd know. And those programs are available on all systems now. -- Bill Moran Collaborative Fusion Inc. [EMAIL PROTECTED] Phone: 412-422-3463x4023 ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Exclusive binary files
On Sat, Sep 01, 2007 at 06:30:20PM -0400, Mike Meyer wrote: > On Sat, 1 Sep 2007 14:27:42 -0300 "Klaus Schneider" <[EMAIL PROTECTED]> wrote: > > Well, anybody know a way to make the FreeBSD run just binaries that I have > > compiled? > > In general, it's impossible. There's no way the system can know that > you compiled a binary. There are a number of things you could do with > a custom kernel and toolchain to indicate that you compiled the binary > (like Peter's changing of ELF OSABI), but that's just security through > obscurity. If someone figures out those changes and replicates them, > you lose. You mean using cryptographic hashes to ensure that binaries match those you compiled is impossible? Something like NetBSD's veriexec? Joerg ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: what happened to make world?
> : > On Thursday 30 August 2007, Pietro Cerutti wrote: > : >> # make world > : >> WARNING: make world will overwrite your existing FreeBSD > : >> installation without also building and installing a new > : >> kernel. This can be dangerous. Please read the handbook, > : >> 'Rebuilding world', for how to upgrade your system. > : >> Define DESTDIR to where you want to install FreeBSD, > : >> including /, to override this warning and proceed as usual. > : >> You may get the historical 'make world' behavior by defining > : >> HISTORICAL_MAKE_WORLD. You should understand the implications > : >> before doing this. [...] > : I don't want my OS to treat me like a stupid. > > I will note that since we switched to the multi-phase world with > explicit reboot instructions, the support load for 'oh no, I shot > myself in the foot' has gone way down. There are times that one must > put a few safety rails in place. Since we have limited resources for > support for users, it is better to make them make sure they know what > they are doing so we can focus our resources better. > > Sometimes we have to optimize for developer time in the tradeoffs that > are made. Against any bit of modesty that's left in me, I'll crawl out of my cave for a second here -- to make a wise comment, no doubt ;) Not trying to start offtopic, just a little remark that's of importance to me (and to many other FreeBSD users, I bet). Not every FreeBSD user is [still] a "computer enthusiast". It just so happens that the OS at the time is the best one for many, many different uses, such as: server, router, research workstation, 'desktop', etc. It is basically an excellent universal tool for many (computer_science|IT)-unrelated tasks, e.g. machine in a physics lab. The ideal tool, of course, is the one that Just Works. Some of the folks using it can't afford the time expense of figuring out how exactly it's geared -- as long as things are working. If it Just Dies at any wrong move -- then, well, one can loose a lot of time, and be pretty screwed. I just hope that you developers won't be forgetting about the users. None of that "Are you sure?" nonsense is needed (it interferes with work as one gains experience), but just a helpful info message or a warning at the right moment is sure nice -- it makes things less painful and more productive. You see, it'd make me really sad to see FBSD go in the direction of Linux one day, and be geared towards (hackish) developers. Meaningless (to a mere mortal) error messages, obscure ways of doing things, chaotic development, and so on. Quite user-unfriendly. These things aren't "bad", they just tend to make the OS less useful as a tool. BTW, if this thread doesn't burn out, then perhaps it's about time it should start drifting in the general direction of [EMAIL PROTECTED] > Warner [SorAlx] ridin' VS1400 ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: How TLS is used in Kernel thread
On Thu, 2007-08-30 at 14:20 -0700, Jin Guojun wrote: > By looking through _pthread_create() code and find it uses a magic > cookie -- TLS -- created > by rtld_allocate_tls(), and passed into kernel by sysarch() via > _tcb_set() / _kcb_set(). > > The information seems to be set by rtld (ld-elf.so.1) in digest_phdr() > under tag PT_TLS. > But it is very magic for where the TLS object is created and how it is > passed to digest_phdr(). > > The whole object passed into kernel (as sd.gsbase) looks like this: > > TCB: __ > | TLS | TCB | > |__|___| > > Can someone give some basic exaplain on following questions? > > 1) What TLS stand for? Its used to implement Thread-Local-Storage variables. These are global variables declared with the '__thread' keyword. Each variable declared in this way has a per-thread value (i.e. each thread has a private copy of the variable). > 2) Where TLS object is created? (below is the tls assigned, but I couls > not find where ph is from) > case PT_TLS: > obj->tlsindex = 1; > obj->tlssize = ph->p_memsz; > obj->tlsalign = ph->p_align; > obj->tlsinitsize = ph->p_filesz; > obj->tlsinit = (void*) ph->p_vaddr; Most of the work of dealing with TLS happens in the runtime linker /libexec/ld-elf.so.1. The runtime linker calculates the TLS size based on the TLS usage of all loaded libraries. The thread library uses an internal interface to rtld (_rtld_allocate_tls and _rtld_free_tls) during thread creation and destruction to allocate and free the TLS blocks. As you have seen, the memory allocated also includes the thread-library's control structures (which includes the saved register set etc.). Static programs have a slightly simpler mechanism (simpler because there is only the main program and no dynamic libraries). This is handled in src/lib/libc/gen/tls.c. > > 3) Where in kernel the TLS is used for thread operation? The kernel doesn't use this information at all. It simply provides support for the thread libraries needs. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
