Re: using git for freebsd development
[EMAIL PROTECTED] wrote: The following can be considered as a followup to the excellent FreeBSD/GIT wiki page: http://wiki.freebsd.org/GitConversion [...] All of the tools either required source CVS repository to be available locally or worked much faster in that case, so the first thing to do was to get src-all from my local cvsup mirror. Easy. Everyone who tries converting freebsd's cvs repository to joe-random-RCS attempts to import the entire source tree as a single project. Honestly, it covers too broad a spectrum. Separate these projects into the cvsup collections: src-sys, src-bin, src-lib, etc.. You won't be able to simply tag a single branch into a full system release without a wrapper script to handle your collections, but that's a small price to pay for the added robustness, separation of privilege, and smaller-scale potential for conflict. In fact, even src-bin may be too broad, and it may make sense to have separate projects within the collection hierarchy. This would, at least, make reparenting projects (say, from src-bin to src-usrbin) easier. ari ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: binary file within a shell script
[EMAIL PROTECTED] wrote: I would like to use one exec file from a shellscript but I would like it to be incorporated in the same file, like Nvidia do for its FreeBSD drivers. How can I do this in a convenient way ? I haven't looked at nvidia's driver packaging, but you can embed binaries into shell scripts using uuencode or base64. Example: % cat test.sh #!/bin/ksh echo *** generating ls... file=`mktemp /tmp/ls.XX` [[ $? -eq 0 ]] || exit 1 uudecode -o $lsfile '__EOM__' ^D % uuencode ls /bin/ls test.sh % cat test.sh __EOM__ chmod +x $lsfile echo *** running $lsfile ... $lsfile echo *** cleaning up rm -f $lsfile ^D Note that i used single quotes in the here-document initialization, so there won't be any shell expansion of the uuencoded data. A few commonly-installed programs that may suit your needs: - uuencode / uudecode - base64 - b64 - openssl base64 If relying on one of the above is infeasible: You can't portably use inline binary data in a shell script without preprocessing it (as with one of the above programs), since most shells can't handle binary zeros; shar(1) fails in this case. You could, theoretically, write a small, clever wrapper function to account for the issue. You'd also have to ensure that regexp(^__EOM__$) (in the above example) doesn't exist within the file contents, and note that excessively long lines may not be handled efficiently by the shell. You'll need to account for files that do or don't end in a newline, possibly by always appending an extra newline, then stripping it upon extraction. Lastly, you'll need to consider whether you must account for CR/LF conversion in file transfers or while editing your script. You probably won't want to deal with all of this, and would be better off leaving it for out-of-band extraction, such as with dan's gzexe suggestion. You'll still need to determine whether CR/LF conversion may be an issue for you. ari ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: binary file within a shell script
[EMAIL PROTECTED] wrote: echo *** generating ls... file=`mktemp /tmp/ls.XX` [[ $? -eq 0 ]] || exit 1 Er, s/^file/lsfile/, obviously. ari ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: encrypted executables
[EMAIL PROTECTED] wrote: ari edelkind [EMAIL PROTECTED] writes: Keep in mind that ptrace(PT_ATTACH,...) will fail if a process is already being traced. As for core files, a process can use setrlimit(RLIMIT_CORE,...) to disable core dumps, and individual memory pages may be encrypted or unloaded, to be decrypted or loaded on demand. The person running the application can trivially replace ktrace(), ptrace() and setrlimit() with non-functional stubs using LD_PRELOAD. And any application that executes its own code before running the system's dynamic loader -- or is statically linked, for that matter -- is free to unset LD_PRELOAD. There are many attack vectors. There are plenty of countermeasures. There are numerous attacks on each countermeasure. It goes on. This is all common knowledge, even among those creating anti-reverse-engineering techniques; in fact, it's usually prominently stated in an included disclaimer. It's unfortunate to note that, in many countries these days, the most effective deterrent against attacks on binary encryption is legal action. Some corporations add just-in-time page decryption to their binaries specifically for this recourse (e.g., against a competitor who creates applications that hook into the original software). ari ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: encrypted executables
#!/usr/local/bin/mysecyritywrapper ...encryted code goes where... In this way. it'll be hard to use truss, ktrace, strace etc... No, not really. All of those tools can trace through to sub-processes, so whenever the code gets decrypted and starts executing (whether it's in the main process or in a sub-process), they'll be able to follow the system calls it makes. Keep in mind that ptrace(PT_ATTACH,...) will fail if a process is already being traced. As for core files, a process can use setrlimit(RLIMIT_CORE,...) to disable core dumps, and individual memory pages may be encrypted or unloaded, to be decrypted or loaded on demand. An approach that handles all of the above, with the possible exception of setrlimit(RLIMIT_CORE,...), is shiva, though it's available only for linux and distributed as an executable. http://www.securiteam.com/tools/5XP041FA0U.html Even then, the developers explicitly state that this can only slow the determined attacker in his endeavors, but the solutions everyone seems to be proposing here won't help. Mind you, it's true that disabling core dumps with a resource limit doesn't keep one from creating a core image using gcore, but since gcore generally must either attach to a process using ptrace() or access mapped code segments in the original binary (depending on the implementation), it won't help in such a case, either. That said, here's a set of slides from a talk on attacking shiva-encrypted binaries: http://www.blackhat.com/presentations/bh-federal-03/bh-federal-03-eagle/bh-fed-03-eagle.pdf ari ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: encrypted executables
[EMAIL PROTECTED] wrote: What prevents me from patching the kernel (!) to just ignore the resource limit? Nothing. Exactly! I mean, it won't help that much if you have pages that haven't been loaded or decrypted. But if you're patching the kernel anyway, you can always have it log the decrypted pages as they're loaded. There wasn't anything in my original e-mail that should make you think i was claiming you couldn't defeat binary encryption and protection measures (especially not the link that i included about defeating shiva). But naive simplistic methods are... just that. ari ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Patch RFC: Promise SATA300 TX4 hardware bug workaround.
Hi, On man, nov 19, 2007 at 09:02:33 +0100, Søren Schmidt wrote: Hi All! I'd like to get the final verdict of the attached patch and if it fixes the problem or not. Please test and report, its a bit urgent if it need to get into R7 :) I have Promise TX2 (PDC20575). It didn't work with 7.0 betas before, but with this patch things run as well as they did on 6.x. Ari S. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Problem about libnet on FreeBSD 6.0
[EMAIL PROTECTED] wrote: http://lists.freebsd.org/pipermail/freebsd-hackers/2005-December/014986.html The problem is that libnet defines ether_addr without regard for the fact that it's defined in our system headers. This is a bug in libnet, not FreeBSD. No one claimed otherwise -- hence the 'BROKEN_LIBNET' tag in my post. In particular, libnet/libnet-headers.h has this code, which is very Linux-centric and works around the duplicate definition problem on Linux, but doesn't help anyone on other platforms. 391 #if (!__GLIBC__) This is typical for libnet, and it has run into compatibility problems of this sort in the past on systems other than freebsd. Search for edelkind libnet or redefinition libnet on google for some of these. ari ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Problem about libnet on FreeBSD 6.0
[EMAIL PROTECTED] wrote: On 12/31/05, Gilbert Fernandes [EMAIL PROTECTED] wrote: I find that I can't include net/ethernet.h when I programming with libnet,because $(CC) complains that struct ether_addr redefined. But I need some definitions in net/ethernet.h,struct ether_header etc. Currently,I just copy the definitions I need from net/ethernet.h,but it seems very ugly.Any one has some good ideas? Here is my include lines, #include .. #include net/ethernet.h #include pcap.h #include libnet.h ... and this is the error, $(CC) said /usr/local/include/./libnet/libnet-headers.h:393: error: redefinition of `struct ether_addr' Assuming that either the practical contents of 'struct ether_addr' are the same for both definitions or that it doesn't matter for any inline functions you may be using within the header file (chances are, this assumption is valid): #include net/ethernet.h #include pcap.h #define ether_addr ether_addr_BROKEN_LIBNET # include libnet.h #undef ether_addr ari ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Problem about libnet on FreeBSD 6.0
[EMAIL PROTECTED] wrote: Did you read my post? Or are you not on the list? I sent my response directly to the list, not including you specifically. [...] I am on the list,and I don't receive your post. I think you can send post specifically to me and cc to the list :-). Thanks. In the future, please respond to personal mails personally. Neither my direct e-mail address nor this mail were intended for public viewing. The post to which i was referring is: http://lists.freebsd.org/pipermail/freebsd-hackers/2005-December/014986.html ari ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Using sysarch specific syscalls in assembly?
On 8/9/2005, alexander [EMAIL PROTECTED] wrote: [...] Unfortunately I'm experiencing some problems right now. From time to time I'm getting a 'Bus error: 10 (core dumped)' This however appears randomly. One time I run the app everything works fine,the next time it core dumps. Are there any errors in my code? %define SYSARCH165 ; syscall sysarch(2) %define I386_SET_IOPERM 4 ; i386_set_ioperm(2) number ioperm_argsdd 378h dd 3 dd 1 OpenIO: push byte ioperm_args push dword I386_SET_IOPERM mov eax,SYSARCH Call _syscall [...] You need to push a _pointer_ to a structure as your second argument to sysarch(2). This means something more along the lines of: ioperm_args dd 378h dd 3 dd 1 argp dd ioperm_args [...] push dword argp push dword I386_SET_IOPERM [...] Get this wrong, and you'll have unpredictable results. ari ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Using sysarch specific syscalls in assembly?
On 8/8/2005, alexander [EMAIL PROTECTED] wrote: [...] i386_set_ioperm(2) states that this procedure is a system call. So it should be easily accessable through assembly language and it's specific syscall id. Unfortunately I wasn't able to find the syscall id in any of the syscalls.master files that are part of the source tree. machine/sysarch.h states that this is a sysarch specific syscall for i386 (hence the i386_*). The following definitions are being made: #define I386_GET_IOPERM 3 #define I386_SET_IOPERM 4 These syscall numbers however are already taken by read(2) and write(2). So how can I make use of these i386 specific syscalls? Is it even possible? If you're unsure of how a function is called, you can always check the C library, under 'src/lib/libc/'. I won't repeat john baldwin's answer, but it's exactly what you'd find there. That said, C library calls are no more difficult to perform from assembly language than system calls, so long as you're willing to link in the standard C library. If you're trying to be more portable, then unless you have specific reasons for not doing so, perhaps it's something you'd like to consider. ari ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Creating Compressed Loop FS from stdin
[EMAIL PROTECTED] wrote: It will not help, since AFAIK you can't seek stdin anyway, or even if I am wrong and you can seek it to the end you will be unable to seek it backward. I tested the patch before posting it, fully expecting to find that stdin really cannot be seeked (sought? :), and surprisingly it worked, at least on RELENG_5 as of today! You can always seek stdin, if stdin happens to be associated with a seekable descriptor. It isn't given any special treatment simply because it has a vector of 0. That is, if you use something along the lines of: % ./seekme /etc/services then /etc/services is associated with descriptor 0, and you can seek all you like. If you use % cat /etc/services |./seekme ... then the descriptor isn't associated with a file, and you'll run into problems. ari ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: freebsd asm
[EMAIL PROTECTED] said this stuff: [...] [demon]~$ cat hello.asm %include 'system.inc' section .data holadb 'Hola', 0Ah hbytes equ $-hola section .text global _start _start: pushdword hbytes pushdword hola pushdword stdout sys.write pushdword 0 sys.exit [demon]~$ nasm -f elf hello.asm hello.asm:1: fatal: unable to open include file `system.inc' ?Where is that file?... the -current port of nasm is incomplete ? system.inc is not a part of nasm. Ok... we take some modifications... %include 'system.inc' pushdword stdout , and we replace it with pushdword 1 nasm also has no knowledge of sys.func style directives, so they are ignored. The directives in question would be located in the system.inc file that you don't have, and your program may as well be: holadb 'Hola', 0Ah hbytes equ $-hola section .text global _start _start: pushdword hbytes pushdword hola pushdword 1 pushdword 0 ... which doesn't exit, therefore your program accesses memory addresses that aren't meant to supply program code, and it crashes. Freebsd system calls are generally accessed using interrupt vector 0x80. The function that deals with this interrupt in the kernel expects the number of the system call in eax, and it expects the program to have called a function along the way. Thus, it's looking for the following stack structure: [][][][] : return address, inserted by 'call' instruction : descriptor vector : string address : number of bytes to write. To get this, you can try something like the following: holadb 'Hola', 0Ah hbytes equ $-hola section .text global _start _start: pushdword hbytes pushdword hola pushdword 1 mov eax,4 ; SYS_write calldoint pushdword 0 mov eax,1 ; SYS_exit calldoint doint: int 0x80 ret You can find the necessary system call numbers in /usr/include/sys/syscall.h . ari ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Strange behaviour in assembly language program
[EMAIL PROTECTED] said this stuff: This code works to return 0x57: 31 c0 40 6a 57 50 cd 80 But that needs 8 bytes! Can't it be shortened? I noticed that some registers contain zero on program startup. Can I safely assume they are always initialized to zero and just leave that 31 c0 out? Freebsd explicitly zeros its registers before executing a program (it then sets specific registers, such as the program counter, flags, and stack pointer). This behavior takes place in an architecture-dependent function, however, so one cannot take for granted that such a thing will occur, nor can one necessarily presume that all generic registers will be zero (indeed, on i386, ebx is set to ps_strings, which may be nonzero when executing bsdi binaries). Still, this is the case as of freebsd 4.5 (alpha, i386) and 5.1 (alpha, amd64, i386, sparc64). Those are the versions and architectures that i briefly checked. This information is in the files with pattern: arch/arch/machdep.c The function in question is exec_setregs on freebsd 5.x, or setregs on freebsd 4.x. ari ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Strange behaviour in assembly language program
[EMAIL PROTECTED] said this stuff: .text .global _start _start: pushl $8 pushl $0 movl$1, %eax int $0x80 With this suggestion, it always returns 0 instead of 1. Shouldn't pushl place 4 bytes on the stack? It translates into the instruction 0x6A (pushes only one byte). 32-bit, 80386-based processors cannot push one byte onto the stack; they can push only in 2- or 4-byte increments (word or double-word). While instruction 0x6a pushes an immediate one-byte value, this is only to save instruction space. The number is in fact pushed as a 32-bit (sign-extended) value. 6a 08 should have the same effect as 68 08 00 00 00 On freebsd, using a native binary format, the above sample should return 8. It works properly on any system that i've checked. I'd be interested in seeing your compiled binary if yours doesn't. BTW, when I assemble it with as(1), there is always an extra instruction after my code, and it's a different one each time (and it's always one that effectively does nothing). Who ordered that? Is it because of alignment constraints in the ELF file? Each section must be aligned on a 4-byte boundary (this is not specific to ELF). This can be duplicated by adding .align 4 as the last instruction. Because the text section is intended for executable code, as(1) offers non-operation instructions (which should be unnecessary in any situation where a programmer doesn't know what he's getting himself into). Newer versions of gnu as(1) seem to pad this with zeros, which you can duplicate with: .align 4, 0 ari ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Strange behaviour in assembly language program
[EMAIL PROTECTED] said this stuff: Finally I came up with the simplest ASM program that reproduces the error. Here it is: .text .global _start _start: pushl $0 movl$1, %eax int $0x80 I looked everywhere (Developer's handbook, Google, ...) to find the solution, but all resources I consulted tell me this is the right way to do it. This program, however, always exits with 1 regardless of the value I push. The kernel expects the interrupt to take place from within a function. Try: .text .global _start _start: pushl $8 movl$1, %eax calldoint doint: int $0x80 Or, if you really want the program as simple as possible, you can push 0, eax, garbage, anything onto the stack in place of the return address: .text .global _start _start: pushl $8 pushl $0 movl$1, %eax int $0x80 ari ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: OT: tftp server
You may also wish to look at firewall rules. If return-udp packets are filtered, one may run into transfer problems with tftp, even using stateful udp inspection. The return udp source port will be the server's transfer identification number, and this will not often be port 69, as the filter would expect from the state table. If you have implemented filtering, you should check into this. ari [EMAIL PROTECTED] said this stuff: On Tue, 24 Feb 2004, Ganbold wrote: Maybe this is off topic question. I'm looking for good tftp server in FreeBSD. I used default tftp server in FreeBSD and had some problems. It sometimes hangs without any response. Can somebody recommend me tftp server in FreeBSD/Unix/Linux? I can't recommend an alternative tftp server, but I can offer some help debugging the current one -- the tftp server is pretty widely used, and I haven't seen any other reports of this. Could you expand a bit on hangs without any response -- do individual transfers stall, or the entire tftp server? What flags are you using to tftpd in inetd.conf? If you use a second client at the same time, does it also appear to be hung? What clients are you using? Robert N M Watson FreeBSD Core Team, TrustedBSD Projects [EMAIL PROTECTED] Senior Research Scientist, McAfee Research ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: integer and long max/min values
'Tis a bit of a waste of cpu time there. On a two's complement system, which is probably all you'll come by, you can find UINT_MAX by setting an unsigned integer to -1: unsigned int i_max = -1; A slightly more architecturally independent way of finding UINT_MAX would be to set an unsigned integer to the complement of its zero: unsigned int i_max = ~(unsigned int)0; Either way, you can find the positive signed maximum by dividing your result by two (discarding the remainder). Try the following: #include limits.h #include assert.h ... assert ((unsigned int)-1 == UINT_MAX); assert (~(unsigned int)0 == UINT_MAX); assert (((unsigned int)-1)/2 == INT_MAX); assert ((~(unsigned int)0)/2 == INT_MAX); ... Some may argue against this method, but using an unsigned complement of zero should hold at least the portability of assuming NULL to be false. The *_MAX macros, of course, should still be used whenever possible. ari [EMAIL PROTECTED] said this stuff: Write a simple C program to ++ an int or long variable and see when it overflows. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of ext Tim Kientzle Sent: Friday, November 21, 2003 12:24 AM To: Jay Sern Liew Cc: [EMAIL PROTECTED] Subject: Re: integer and long max/min values Jay Sern Liew wrote: how do I find out the maximum (and minimum) value a long and int will hold in C? (before it overflows or underflows) #include limits.h INT_MAX and INT_MIN are the max/min values for an int LONG_MAX and LONG_MIN are the max/min values for long. Also, see stdint.h, which is defined in C99. Also, buy a good C reference book. ;-) Tim Kientzle ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: mtime and directories...
[EMAIL PROTECTED] said this stuff:
Changing a file, of course, results in a change to its modification
time. Am I correct in determining that the mtime of the enclosing
directory is also updated?
The mtime of a directory is updated when the directory file changes.
Directory files contain filenames and their associated inode numbers.
Modify any of that information (e.g., create a new file, remove or
rename an existing file), and the mtime will be changed. Changing the
ctime or mtime of a file within a directory does not modify that of the
directory itself.
The reason I'm asking this is because I need to be able to determine if
any file has changed within a directory from a shell script, Perl, or
Python. All I need to know is if at least one file has changed. I don't
need to find all such files. [Sidelight: anyone know how, if possible,
to stop find after finding one file? I can't figure this one out alone.]
% find /some/dir criteria |head -1
In this case, 'head' will exit after reading one line, causing 'find' to
receive a SIGPIPE if it tries writing more data. The 'find' command
doesn't typically trap SIGPIPE, so the process will exit. Of course, it
won't receive the signal immediately --- only if it calls write(2)
again, and on descriptor 1. If 'find' matches only one file, it will
wind up seeking through the entire tree. This may not be sufficient for
your application.
To truly make find exit after it matches one file, you can do something
along the lines of:
% prescript find /some/dir criteria -exec postscript '{}' \;
... where prescript contains a somewhat more error-tolerant version of
the following:
#!/bin/sh
echo $$ /pid/dir/find.pid
exec $@
... and postscript contains a somewhat more useful version of the
following:
#!/bin/sh
dostuffwith $@
pid=`cat /pid/dir/find.pid`
rm -f /pid/dir/find.pid
kill $pid
My initial solution was to use 'find' to find any files newer than a
marker file. However, I believe I've determined that the mtime of
enclosing directories also changes to reflect the last file that was
updated within its hierarchy. So, it makes sense that I simply check
the directory that contains the marker file.
Again, a directory's modification time is updated only if the actual
directory contents have changed, not the contents or inodes of the files
within it.
ari
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [future patch] dropping user privileges on demand
[EMAIL PROTECTED] said this stuff: ari wrote: Currently, root is the only user that can actually drop significant privileges, as root is the only user that has access to such functions. This is flawed --- any user should be able to relinquish his privileges, and i've begun a patch to put this into effect. However, the fact that this is a security-related kernel feature modification warrants peer-review, in both design and implementation. It would be unwise of me to create the patch without consulting such. The web page that discusses the patch may be found at: http://www.episec.com/people/edelkind/patches/kernel/flowpriv/ I welcome any discussion and criticism. The biggest risk is that you may have aquired something priviliged in your process memory space or file descriptor table. If you are then fully unpriviliged, then things like ptrace(), core dumps etc, become a minefield. For example, if a process did a getpwnam() before dropping privs, then it may have a cached copy of the secret master.passwd data in memory. Anyway, thats something to keep in mind. True, but you have this problem if you don't drop privileges, as well. The programmer must account for such things, either way. However, since even root-owned processes will be able to drop most system call privileges, programmers must be careful not to lull themselves into a false sense of security if, for example, dumping core is still an option. Dumping core should be disabled with filesystem writes, however, and ptrace should be included in a class of items to disable. ari ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [future patch] dropping user privileges on demand
[EMAIL PROTECTED] said this stuff: In the last episode (Aug 17), ari said: Currently, root is the only user that can actually drop significant privileges, as root is the only user that has access to such functions. This is flawed --- any user should be able to relinquish his privileges, and i've begun a patch to put this into effect. Have you taken a look at Cerb? http://cerber.sourceforge.net/ It does something similar, but uses a C-like language to control a processes actions. This lets you get extremely fine-grained control (allow httpd to bind to only port 80, once), but the rules run as root, so they can grant as well as revoke privileges. A useful modification would be to allow users to submit their own policies that can only disallow actions (i.e. all arguments and process variables are read-only, and the script can either pass the syscall through or return a failure code, nothing else). I hadn't looked at cerb, though a C interface to systrace, or the modification of systrace to add a specialty function to the kernel, had passed though my mind. However, systrace is a good bit more complex than this should be, and the performance penalty can be significant. Neither programmers nor admins should be expected to implement something that slows down their programs on a wide scale, even if it would be advisable from a security standpoint. The implementation of flowpriv, however, will have a negligible performance impact (about three memory references per system call). I _do_ believe that systrace and flowpriv should work together, but i don't believe they should be consolidated. I have proof-of-concept code now, as a modification of 5.1-RELEASE-p2. I'll make a patch as soon as i get a chance; the idea may be a bit clearer then. ari ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [future patch] dropping user privileges on demand
[EMAIL PROTECTED] said this stuff: Let me explain you something. flowpriv isn't a well known standard. If you susspect that developers will rewrite their programms (and there are many things for rewritting to use such mechanism) you're wrong. This is my opinion. That's why I've decide to create CerbNG - it is totally transparent for applications and I think Niels Provos shares my opinion in systrace. And i'm sure it is and will be useful. However, performance drawbacks are nothing to sneeze at. Additionally, systrace acts on the system calls you specify. If programmers are to take advantage of the interface, you can't expect them to drop every unnecessary system call that may potentially do harm. This makes their applications cumbersome and utterly nonportable. They must be able to take advantage of class-based privileges, which will automatically do what they're supposed to do on different systems. An example that i've used in the past is creating a file on the filesystem. The programmer should be able to drop filesystem creation permissions, without worrying about the need to drop open, mkfifo, bind, link, symlink, mkdir, and any other system calls that happen to be available in this particular kernel version. Note that any patches one adds to his kernel may also affect the available system calls. Of course it isn't a well-known standard. It hasn't even been written yet, aside from some proof-of-concept code that i have yet to package up and put on the site. Nor was systrace a well-known standard before it was written (not that it's necessarily a standard now, though it is quite popular). I wouldn't expect programmers to immediately begin using this code; if it catches on, however, and it's implemented in a number of different operating systems, then there stands a greater chance. If it doesn't catch on and isn't used, then so be it. So while i do appreciate the suggestion of using systrace, it's not something i'm considering. What i _am_ considering, however, is tying this into mandatory access controls, for which hooks are already in the kernel. But MAC doesn't seem to be fully implemented yet, as of 5.1-RELEASE. I am threatening neither cerb nor systrace by implementing flowpriv[1]. I believe they serve different purposes, and should work together quite well. ari [1] The name may or may not stay flowpriv. Again, it's in its early stages, and this is a working title. F is for function; low and priv relate to dropping privileges. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [future patch] dropping user privileges on demand
[EMAIL PROTECTED] said this stuff: On Thu, Aug 21, 2003 at 12:39:00AM -0700 or thereabouts, Kris Kennaway wrote: Exercise for the reader: find a situation where the failure to perform a syscall that normally succeeds, leads to privilege escalation :-) setuid(), seteuid(), setruid() There seems to be some misunderstanding of what kris meant. He was referring to a system call that is so poised to succeed that programmers will often not bother checking for an error value. For example, if one winds up not having privileges to call exit(), then, say, an authentication failure may not abort execution. If close() is not allowed, then a sensitive file descriptor may be left open as the program continues to run. If unlink() fails, one may fall victim to following an unintended symbolic link upon file creation. If chroot() or chdir() fails, a program may not be able to properly insert itself into a chroot() environment. If getpid() fails, the program may not properly distinguish intended privileges. If mprotect() fails, one may not be able to remove the writable bit from a memory page. If munmap() fails, one may suffer memory leaks. If quotactl fails, user quotas may not take effect. The setuid() family of functions will only cause a problem here if a program is either running as root or has a saved or effective uid that is different from its real uid. Even then, having setuid() disabled may be either beneficial or detrimental, depending on what the programmer expects or is attempting. There are all sorts of ways for the failure of system calls at inopportune times to lead to an elevation of privileges. But the point is, this isn't (or shouldn't be) for the administrator to worry about; the programmer knows that while modifying his code, he should be careful not to introduce security problems. If a programmer is able to disable the exit() system call, he should know what he's getting himself into when he does so. The patch i'm proposing isn't going to allow the disabling of arbitrary system calls; not every function call will even be included in a class. For example, the ability to block memory-related routines would probably not be a good idea, and doing so may break your program, depending merely on which standard c library you use. If you expect memory leaks, resource limits can keep your process at bay. ari ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [future patch] dropping user privileges on demand
[EMAIL PROTECTED] said this stuff: As I said. Stuff like systrace or cerb doesn't need to be standarized, because it is transparent for applications. It doesn't need any work from userland application programmer. That's why it is easy to addopt for non-BSD-licensed applications or even for non-open-source applications. This is precisely why i began working on the project. What's transparent to applications is not transparent to administrators. So instead of having one programmer (or even a group of programmers) fix the code, you have every administrator correct for it. Of course, it would be best if every administrator verified that it acted properly anyway, but that's simply not going to happen. Sure, some programmers are lazy. Some programmers don't care. But some will benefit, and that's what matters. This isn't intended to solve all the world's coding problems. It will probably never be used by as many programmers as systrace will by administrators. It's just furthering the unix mentality of shedding privileges, without granting additional ones. You seem to think that the idea is a security hack. It isn't. It's more of a security model. ari ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
[future patch] dropping user privileges on demand
Currently, root is the only user that can actually drop significant privileges, as root is the only user that has access to such functions. This is flawed --- any user should be able to relinquish his privileges, and i've begun a patch to put this into effect. However, the fact that this is a security-related kernel feature modification warrants peer-review, in both design and implementation. It would be unwise of me to create the patch without consulting such. The web page that discusses the patch may be found at: http://www.episec.com/people/edelkind/patches/kernel/flowpriv/ I welcome any discussion and criticism. ari ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Problem linking/integrating Socket stuff into my driver code
Hi everyone,
I wrote pseudo-device driver for FreeBSD kernel. It safely comes up at boot
time. There is also a corresponding device node "/dev/mydevice" for my code,
so that whenever someone makes an:
fd = open("/dev/mydevice", .. );
ioctl( fd, COMMAND );
the "mydevioctl()" function within my code will take care of the COMMAND
requested.
* NOW , My problem is !! **
I tried to add some networking functionality to my driver. Although I
#include'd every required socket and net related header in my code
sys/socket.h, netdb.h, netinet/in.h and etc. I get the errors
"Undefined reference to socket()" , same for connect(), gethostbyname(),
accept() etc. In my previous life B.K. ( Before Kernel ) I used to link to
socket related libraries ( -lsocket, -lnls ), but this is not a standalone
program and I am not supposed to make explicit linking to any library. This
is KERNEL anyway, it has object code for almost every standard function you
may want to use (e.g.socket() ..) For example: kern/uipc_syscalls.o has the
socket() definition and uipc_syscalls.o is already in the list of object
files to be used in kernel make; all being compiled together.
After including the required header files and after ensuring with ( nm -s
uipc_syscalls.o ) that socket() is defined there, how do I get my code to
see these functions.
Some Bullets that might help
--
* FUNNY:: I wrote a small client/server chat program (for testing) ;compiled
both client and server code using "cc -o server server.c", "cc -o client
client.c" and DID NOT LINK any special library... IT WORKED ??!! I put
server code on another PC over network and they get to communicate with the
client. "cc" somehow knows where to link I guess (Is there a list of the
libraries that cc links somewhere? or does it just look under /usr/lib)..
And the second funny thing is that, when I do a symbol lookup " nm -s
client" on the client program the functions that I use , socket(),
gethostbyname() still look U ( Unresolved, Undefined ?)
* Kernel Makefile first compile everything with "cc -c " , i.e. "don't link
at this time" option * After everything is compiled, kernel links them
together using linker ld
* cc without any option does all the compiling and linking job, but I am
bound to use the KERNEL's rules "cc -c" first then link everything together.
* Other drivers in the kernel ( e.g. aha SCSI driver) don't have any compile
and linking problem and usually none of them need a special treatment for
linking. Check /usr/src/sys/compile/GENERIC - Makefile . NORMAL_C type of
compilation is enough for them.
Please Respond to: [EMAIL PROTECTED] AND/OR [EMAIL PROTECTED]
Best Regards,
Ismail Ari
HP Labs
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
