Re: valgrind or workalike on FreeBSD/amd64 7.0/8.0?
On Tue, Feb 12, 2008 at 11:51:19AM -0800, Xin LI wrote: [..] > > Hi, > > Is there anyone working on valgrind on newer FreeBSD releases, or some > work-alikes? > > Cheers, Yes, check out the //depot/projects/valgrind/... perforce project. It works pretty well. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: auditpipe leak?
On Sun, Oct 21, 2007 at 01:47:21PM -0400, [EMAIL PROTECTED] wrote: [..] > > crw--- 1 root wheel0, 137 21 Oct 17:51 /dev/auditpipe0 > crw--- 1 root wheel0, 138 21 Oct 17:51 /dev/auditpipe1 > crw--- 1 root wheel0, 141 21 Oct 17:51 /dev/auditpipe2 > crw--- 1 root wheel0, 142 21 Oct 17:51 /dev/auditpipe3 > crw--- 1 root wheel0, 143 21 Oct 17:51 /dev/auditpipe4 > > The numbers seem to increment forever, in testing, I got up to > /dev/auditpipe50 before rebooting to clean them up (I expect > just restarting devfs would've been enough, in retrospect). > This is not a leak, this is a side effect of how device cloning works in devfs. IIRC these will be garbaged collected at some point, and faster if the system requires the resources. -- Christian S.J. Peron [EMAIL PROTECTED] FreeBSD Committer ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Segfault in praudit
I have fixed this issue in the vendor branch. We expect to do an vendor import soon. On Sun, Oct 21, 2007 at 01:42:12PM -0400, [EMAIL PROTECTED] wrote: > FreeBSD 6.2-RELEASE-p8 #2, i386 > > sudo auditreduce -m AUE_REBOOT /dev/auditpipe | praudit > auditreduce in free(): error: junk pointer, too high to make sense > Abort trap (core dumped) > > sudo auditreduce -m AUE_CONNECT /dev/auditpipe | praudit > auditreduce in free(): error: junk pointer, too high to make sense > Abort trap (core dumped) > > Not-exactly-helpful backtrace: > > #0 0x28146ecb in kill () from /lib/libc.so.6 > #1 0x28146e68 in raise () from /lib/libc.so.6 > #2 0x28145b78 in abort () from /lib/libc.so.6 > #3 0x280e2fdb in _UTF8_init () from /lib/libc.so.6 > #4 0xbfbfea28 in ?? () > #5 0x2814cdd3 in sys_nsig () from /lib/libc.so.6 > #6 0x2814ccd3 in sys_nsig () from /lib/libc.so.6 > #7 0x2814cdf0 in sys_nsig () from /lib/libc.so.6 > #8 0x in ?? () > #9 0x28157d80 in ?? () from /lib/libc.so.6 > #10 0xbfbfe6d8 in ?? () > #11 0x280e3009 in _UTF8_init () from /lib/libc.so.6 > #12 0x28157d80 in ?? () from /lib/libc.so.6 > #13 0x2816da24 in _nsyyin () from /lib/libc.so.6 > #14 0xbfbfe788 in ?? () > #15 0x280e3d69 in _UTF8_init () from /lib/libc.so.6 > #16 0x2808a6c0 in ?? () from /usr/lib/libbsm.so.1 > #17 0x2808a6da in ?? () from /usr/lib/libbsm.so.1 > #18 0x2806f558 in ?? () from /libexec/ld-elf.so.1 > #19 0x08048574 in ?? () > #20 0x0001 in ?? () > #21 0xbfbfe724 in ?? () > #22 0x28051863 in find_symdef () from /libexec/ld-elf.so.1 > Previous frame inner to this frame (corrupt stack?) > > Is this a known problem? It occurs when specifying any valid > event name. > > -- > dc > ___ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "[EMAIL PROTECTED]" -- Christian S.J. Peron [EMAIL PROTECTED] FreeBSD Committer ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: audit doesn't seem to be working correctly.
On Tue, Oct 09, 2007 at 12:13:04AM -0400, [EMAIL PROTECTED] wrote: [..] > > I completely missed the replies to this thread. At least > I now know it's due to an actual problem rather than my > inability to follow instructions! > Well, The problem that I thought was there, wasn't actually there, which is why I said to ignore the patch :) I've tried to reproduce the problems you are seeing but I have not been able to. So far I've tried on -CURRENT and RELENG_6. We are aware of some issues on RELENG_6_2 specifically with !i386 architectures (i.e. amd64, sparc64 etc). Is it possible you can send me: (1) The output to uname -a (2) Your /etc/security directory (3) How are you logging in to this machine, SSH? Telnet? (3) is important because the login program will be responsible for setting up the audit ID and preselection masks. Hopefully with this information, we can get to the bottom of this. -- Christian S.J. Peron [EMAIL PROTECTED] FreeBSD Committer ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: audit doesn't seem to be working correctly.
On Mon, Oct 08, 2007 at 01:18:28PM -0500, Christian S.J. Peron wrote: > Please try the attached patch: > > cp audit.diff /usr/src/sys > patch < audit.diff > > Recompile your kernel. > > If please report success/failure to me. > Actually.. ignore this patch. Sorry about that. -- Christian S.J. Peron [EMAIL PROTECTED] FreeBSD Committer ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: audit doesn't seem to be working correctly.
Please try the attached patch:
cp audit.diff /usr/src/sys
patch < audit.diff
Recompile your kernel.
If please report success/failure to me.
On Thu, Oct 04, 2007 at 12:21:19AM -0400, [EMAIL PROTECTED] wrote:
> After reading this article:
>
> http://www.regdeveloper.co.uk/2006/11/13/freebsd_security_event_auditing/
>
> I decided to try audit. I edited /etc/security/audit_control
> as the article (and the handbook example) shows:
>
> dir:/var/audit
> flags:lo,+ex
> minfree:20
> naflags:lo
> policy:cnt
> filesz:0
>
> But having restarted auditd, I don't see audit events for
> process execution being generated. However, if I do this:
>
> dir:/var/audit
> flags:lo
> minfree:20
> naflags:lo,+ex
> policy:cnt
> filesz:0
>
> I get audit records for users executing programs. This seems
> completely wrong to me. Why are these events being classed as
> non-attributable when they're clearly being created by
> authenticated users?
>
> I am running 6.2-RELEASE-p7 which is vanilla apart from the
> addition of options MAC, AUDIT and VESA.
>
> --
> dc
> ___
> freebsd-hackers@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> To unsubscribe, send any mail to "[EMAIL PROTECTED]"
--
Christian S.J. Peron
[EMAIL PROTECTED]
FreeBSD Committer
Index: kern/kern_prot.c
===
RCS file: /home/ncvs/src/sys/kern/kern_prot.c,v
retrieving revision 1.211
diff -u -r1.211 kern_prot.c
--- kern/kern_prot.c 12 Jun 2007 00:11:59 - 1.211
+++ kern/kern_prot.c 8 Oct 2007 17:59:34 -
@@ -1830,6 +1830,7 @@
#ifdef MAC
mac_copy_cred(src, dest);
#endif
+ dest->cr_flags = src->cr_flags;
}
/*
Index: security/audit/audit.c
===
RCS file: /home/ncvs/src/sys/security/audit/audit.c,v
retrieving revision 1.33
diff -u -r1.33 audit.c
--- security/audit/audit.c 1 Jul 2007 20:51:30 - 1.33
+++ security/audit/audit.c 8 Oct 2007 17:59:43 -
@@ -344,7 +344,7 @@
* Decide whether to commit the audit record by checking the error
* value from the system call and using the appropriate audit mask.
*/
- if (ar->k_ar.ar_subj_auid == AU_DEFAUDITID)
+ if ((ar->k_ar_commit & AR_AMASK_GLOBAL) != 0)
aumask = &audit_nae_mask;
else
aumask = &ar->k_ar.ar_subj_amask;
@@ -461,7 +461,7 @@
* event mask or the process audit mask.
*/
auid = td->td_ucred->cr_audit.ai_auid;
- if (auid == AU_DEFAUDITID)
+ if ((td->td_ucred->cr_flags & CRED_AMASK_GLOBAL) != 0)
aumask = &audit_nae_mask;
else
aumask = &td->td_ucred->cr_audit.ai_mask;
@@ -494,6 +494,13 @@
td->td_ar = audit_new(event, td);
else
td->td_ar = NULL;
+ /*
+ * If we have an audit record, and it's referencing the global
+ * preselection mask, set the AR_MASK_GLOBAL flag so we can make
+ * the distinction between the two.
+ */
+ if (td->td_ar != NULL && aumask == &audit_nae_mask)
+ td->td_ar->k_ar_commit |= AR_AMASK_GLOBAL;
}
/*
@@ -540,6 +547,7 @@
{
bzero(&cred->cr_audit, sizeof(cred->cr_audit));
+ cred->cr_flags |= CRED_AMASK_GLOBAL;
}
/*
Index: security/audit/audit_private.h
===
RCS file: /home/ncvs/src/sys/security/audit/audit_private.h,v
retrieving revision 1.16
diff -u -r1.16 audit_private.h
--- security/audit/audit_private.h 1 Jun 2007 21:58:58 - 1.16
+++ security/audit/audit_private.h 8 Oct 2007 17:59:43 -
@@ -86,6 +86,8 @@
#define AR_PRESELECT_USER_TRAIL 0x4000U
#define AR_PRESELECT_USER_PIPE 0x8000U
+#define AR_AMASK_GLOBAL 0x0001U
+
/*
* Audit data is generated as a stream of struct audit_record structures,
* linked by struct kaudit_record, and contain storage for possible audit so
Index: security/audit/audit_syscalls.c
===
RCS file: /home/ncvs/src/sys/security/audit/audit_syscalls.c,v
retrieving revision 1.21
diff -u -r1.21 audit_syscalls.c
--- security/audit/audit_syscalls.c 27 Jun 2007 17:01:15 - 1.21
+++ security/audit/audit_syscalls.c 8 Oct 2007 17:59:43 -
@@ -547,6 +547,7 @@
newcred->cr_audit.ai_termid.at_addr[0] = ai.ai_termid.machine;
newcred->cr_audit.ai_termid.at_port = ai.ai_termid.port;
newcred->cr_audit.ai_termid.at_type = AU_IPv4;
+ newcred->cr_flags &= ~CRED_AMASK_GLOBAL;
td->td_proc->p_ucred = newcred;
PROC_UNLOCK(td->td_proc);
crfree(oldcred);
@@ -604,6 +605,7 @@
if (error)
goto fail;
newcred->cr_audit = aia;
+ newcred->cr_flags &= ~CRED_AMASK_GLOBAL;
td->td_proc->p_ucred = newcred;
PROC_UNLOCK(td->td_proc);
crfree(oldcred);
Index: sys/ucred.h
==
Re: audit doesn't seem to be working correctly.
I think I have isolated the problem and I am working on a fix. For now if you want to experiement with audit you should be able to work around this bug by adding an entry into /etc/security/audit_user. Thanks for your report. On Thu, Oct 04, 2007 at 12:21:19AM -0400, [EMAIL PROTECTED] wrote: > After reading this article: > > http://www.regdeveloper.co.uk/2006/11/13/freebsd_security_event_auditing/ > > I decided to try audit. I edited /etc/security/audit_control > as the article (and the handbook example) shows: > > dir:/var/audit > flags:lo,+ex > minfree:20 > naflags:lo > policy:cnt > filesz:0 > > But having restarted auditd, I don't see audit events for > process execution being generated. However, if I do this: > > dir:/var/audit > flags:lo > minfree:20 > naflags:lo,+ex > policy:cnt > filesz:0 > > I get audit records for users executing programs. This seems > completely wrong to me. Why are these events being classed as > non-attributable when they're clearly being created by > authenticated users? > > I am running 6.2-RELEASE-p7 which is vanilla apart from the > addition of options MAC, AUDIT and VESA. > > -- > dc > ___ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "[EMAIL PROTECTED]" -- Christian S.J. Peron [EMAIL PROTECTED] FreeBSD Committer ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
RE: FreeBSD trusted execution system: beta testers wanted
All Thanks for all the input. I have updated the code as per some of the comments which came in around testing. The following changes were made: -modify setfhash/getfhash to use the filename of the pathname portion. this will un break set/getfhash if it was invoked using ./ or the complete pathname. -the kernel implementation of setfhash was a bad idea. It used to use the utimes syscall. This especially caused problems with various port or source builds on NFS file systems exiting with EIO or various other errors. I replaced the kernel implementation with a sysctl, and modified the setfhash utility to use this instead. -add additional printf's to tell people where/why things went wrong. It should be noted that these printfs are only executed if the module is compiled with DEBUG set. (See the Makefile). -change Makefiles and file locations to be more consistent with the system build practices. NOTE: IF YOU HAVE ALREADY PATCHED YOUR KERNEL SKIP THE KERNEL PATCH/REBUILD cd /usr/src/sys fetch http://www.freebsd.org/~csjp/mac/mac_vnode_mmap.1106783302.diff patch < mac_vnode_mmap.1106783302.diff # REBUILD YOUR KERNEL cd /usr/src/sys/modules mkdir /usr/src/sys/modules/mac_chkexec cd /usr/src/sys/modules/mac_chkexec fetch http://www.freebsd.org/~csjp/mac/Makefile cd /usr/src/usr.sbin fetch http://www.freebsd.org/~csjp/mac/getfhash.165779.shar sh getfhash.165779.shar cd getfhash make make install make clean cd /usr/src/sys/security fetch http://www.freebsd.org/~csjp/mac/mac_chkexec.165827.shar sh mac_chkexec.165827.shar cd /usr/src/sys/modules/mac_chkexec make make install make clean -- Christian S.J. Peron [EMAIL PROTECTED] FreeBSD Committer ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
FreeBSD trusted execution system: beta testers wanted
All,
I have written a trusted execution module and would appreciate if anyone could
help in testing. This module provides a functionality similar to NetBSD's
verified exec mechanism. Once the design details of this security policy has
been solidified, I will be releasing a white paper which describes the
technical implementation in greater detail.
The mac_chkexec policy logic can be found here:
http://people.freebsd.org/~csjp/mac/trustedexec.png
Q: What is mac_chkexec?
A: It's a mandatory access control policy which ensures that if the code
contained in a binary, shell script, shared object or kernel module has
been modified from it's "trusted" form, it can not be executed. It also
ensures that untrusted code can not be executed. I.E. If an adversary
uploads an agent or rogue program, it should not be executed.
In addition, dependencies are supported. Since configuration files,
system databases or other files can alter how a program runs, it is
possible to make the policy verify the integrity of these dependencies
before allowing the execution of the object.
Q: What is required to run mac_chkexec?
A: This policy requires that options MAC be compiled into your kernel.
Since it depends on extended attributes for dependency and checksum
storage, it also requires UFS2. This security policy requires
FreeBSD 5.X
Q: How do I set this up and test it?
A:
cd /usr/src/sys
fetch http://people.freebsd.org/~csjp/mac/mac_vnode_mmap.1106783302.diff
patch < mac_vnode_mmap.1106783302.diff
NOTE: Patch should work against -CURRENT or RELENG_5
Add the following line to your kernel config:
options MAC
Now Recompile and install your kernel.
Download, build and install the mac_chkexec kernel module:
fetch http://people.freebsd.org/~csjp/mac/mac_chkexec.1110510616.tar.gz
tar zxvf mac_chkexec.1110510616.tar.gz
cd mac_chkexec
make
make install
The policy can be loaded using:
kldload mac_chkexec
Download, build and install the set{get}fhash user-space utility:
cd /usr/src/usr.sbin
fetch http://people.freebsd.org/~csjp/mac/getfhash.1110501625.shar
sh getfhash.1110501625.shar
cd getfhash
make
make install
ln -s /usr/sbin/getfhash /usr/sbin/setfhash
Q: I have everything installed, how do I generate my baseline?
A: Easy, load the module and run your system like you would any other day. By
default when you load the module without "enforcing" the policy, the trusted
exec system is in "learning" mode. Which means anytime an object gets
executed, a checksum is computed and stored with the object.
If you do not want to wait for nature to take it course, you can always
force the calculation and storage of checksums using setfhash.
setfhash /bin/ls
Q: How can I see what checksum is currently registered for an object?
A:
getfhash /bin/ls
Q: How can I set dependencies for an object?
A:
setfhash -m /etc/rc.firewall /bin/ipfw
Executables can have more then one dependency. You can use a colon to
separate them:
setfhash -m /path/foo:/path/foo/test /bin/ls
NOTE: DEPENDENCIES PATHNAMES ARE RELATIVE TO THE CALLING PROCESS WITH
COMPLICATES THINGS IS CHROOT OR JAIL ENVIRONMENTS.
Q: OK, I've generated my baseline, now how do I start enforcing the policy?
A:
sysctl security.mac.chkexec.enforce=1
NOTE: If you plan on doing a buildworld, you might want to increase the
cache size to something like 1024
sysctl security.mac.chkexec.cache.objmax=1024
Good luck & Thanks!
--
Christian S.J. Peron
[EMAIL PROTECTED]
FreeBSD Committer
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: GNUstep and libkvm
On Thu, Jan 06, 2005 at 06:21:54PM -0800, Pascal Hofstee wrote: > > I guess to sum it all up it all boils down to the following question. > > Is it intended that kvm_getargv() apparently has a conditional under > which it depends on the existince of a working /proc .. even though > the manpage states this condition is only present for kvm_getenvv ? > > And if kvm_getargv should not depend on /proc ... how can we go about > to fixing this as this is apprently only the case for "short > commandlines" in our current implementation. iirc, kvm_getargv() can (and does first) use a sysctl to retrieve it's data. kvm_getenvv() requires procfs because /proc//mem is currently the more simpler to read a virtual memory address in the context of the process. We are looking at implementing a similar mechanism to the "argv" ps_strings for process environment to get rid of the procfs requirement. pjd has some work done on this but it has not been committed yet. Hope this answers your question. Regards Christian S.J. Peron ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: fixes for ipfw and pf lock ordering issues
On 28 Sep 2004 Wiktor Niesiobedzki wrote:
> pf_socket_lookup(cbb24958,cbb2495c,2,cbb24a0c,c15275a0) at
> pf_socket_lookup+0x22
> pf_test_tcp(cbb249c0,cbb249bc,2,c14d6200,c139e500) at pf_test_tcp+0x648
> pf_test(2,c14b8014,cbb24aa8,c15275a0,c15661c0) at pf_test+0x53d
> pf_check_out(0,cbb24aa8,c14b8014,2,c15275a0) at pf_check_out+0x6d
> pfil_run_hooks(c066da00,cbb24b1c,c14b8014,2,c15275a0) at pfil_run_hooks+0xeb
> ip_output(c139e500,0,cbb24ae8,0,0) at ip_output+0x630
> tcp_twrespond(c18709a0,10,c0607304,69c,1) at tcp_twrespond+0x1ed
> tcp_twstart(c186b380,0,c0606ba2,96f,0) at tcp_twstart+0x1d3
> tcp_input(c139d800,14,c14b8014,1,0) at tcp_input+0x2c39
> ip_input(c139d800,0,c06053ae,e7,c066d098) at ip_input+0x5b0
> netisr_processqueue(c066d098,c0642940,1,c05fb4da,c10d62c0) at
> netisr_processqueu
> e+0x8e
> swi_net(0,0,c05f9b18,269,0) at swi_net+0xe9
> ithread_loop(c10de480,cbb24d48,c05f990f,31f,100) at ithread_loop+0x172
> fork_exit(c04a6520,c10de480,cbb24d48) at fork_exit+0xc6
> fork_trampoline() at fork_trampoline+0x8
> --- trap 0x1, eip = 0, esp = 0xcbb24d7c, ebp = 0 ---
> db>
>
> db> show locks
> exclusive sleep mutex inp (tcpinp) r = 0 (0xc1527630) locked @
> /usr/src/sys/neti
> net/tcp_input.c:737
> exclusive sleep mutex tcp r = 0 (0xc066de6c) locked @
> /usr/src/sys/netinet/tcp_i
> nput.c:611
> db>
>
> (gdb) l *pf_socket_lookup+0x22
> 0xc043a2d2 is in pf_socket_lookup (/usr/src/sys/contrib/pf/net/pf.c:2414).
> 2409#endif
> 2410struct inpcb*inp;
> 2411
> 2412#ifdef __FreeBSD__
> 2413if (inp_arg != NULL) {
> 2414*uid = inp_arg->inp_socket->so_cred->cr_uid;
> 2415*gid = inp_arg->inp_socket->so_cred->cr_groups[0];
> 2416return (1);
> 2417}
> 2418#endif
>
Looks like it could be a bad pointer dereference, have you recompiled
your kernel and the pf/ipfw modules? If not, please try recompiling
your kernel. otherwise I will keep hunting for potentially bad
pointers being passed to the pfil hooks
--
Christian S.J. Peron
[EMAIL PROTECTED]
FreeBSD Committer
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
fixes for ipfw and pf lock ordering issues
Good day folks, we need some beta testers Currently, those who utilize ucred based firewalling, i.e. firewall rules which match based on UID, GID or JAIL ID are subject to lock order problems which often results in the system hard locking. (when giant is not present ... debug.mpsafenet=1). This problem affects all FreeBSD firewalls which implement ucred based matching, namely ipfw and pf. The lock order problem exists due to a layering violation which occurs when the IP stack attempts to acquire locks within lower level stacks such as UDP and TCP. Max Laier (mlaier@) and myself have been working together to solve this problem. Together we have generated a set of diffs which do the following: o Add a pointer to a PCB to pfil_hooks o Modify existing pfil_hooks API to handle this extra argument o Modify the pf and ipfw firewalls to utilize this extra argument so that lookups on local outbound TCP and UDP traffic can be deactivated (removing the requirement for holding INP locks, which was a primary suspect for these lock ordering issues). o Implement a shared locking mechanism for firewall rule chain protection The intended results of these changes are: 1) Remove the lock ordering issues which result in system hard locks 2) Avoid redundant PCB lookup overhead improving the overall performance of ucred based rule sets 3) Improving network and firewall parallelism, shared locks give the OS the ability to run multiple evaluation or rule check activations concurrently, which should increase the overall network throughput on devices which have ipfw or pf firewalls enabled (regardless of whether or not these rules contain ucred based constraints). If anyone could help us test these changes that would be great: download: http://people.freebsd.org/~csjp/inp_pfil_fw_lor_fixes_shared_locks.1096053274.diff cd /usr/src/sys fetch http://people.freebsd.org/~csjp/inp_pfil_fw_lor_fixes_shared_locks.1096053274.diff patch < inp_pfil_fw_lor_fixes_shared_locks.1096053274.diff Recompile your kernel and any related pf or ipfw modules add some user/group/jail based firewall rules Remember, these are pretty beta so ... be gentle :) -- Christian S.J. Peron [EMAIL PROTECTED] FreeBSD Committer ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: shared memory in jails
On 27 Aug 2004 Dmitry Karasik wrote: > > Hi hackers, > > I've been playing with shared memory in jails, and very soon found > out that one jail's segments are visible (didn't check the accesibility > thoroughly) in another, which IMO is against the very idea of the jail. > ( The exact problem is that postgresqls, when run in jails, try to use same > set of IPC keys and (expectedly) fail ). Yes, this is a known issue with prisons. iirc for this very reason we default security.jail.sysvipc_allowed to 0. I think it would be beneficial to solve this problem, however I have not had much time to look into it. -- Christian S.J. Peron [EMAIL PROTECTED] FreeBSD Committer ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
[patch] attach ipfw rules to jails
I have written support for attaching ipfw rules to jails. I am looking for some testers/feedback. http://people.freebsd.org/~csjp/ip_fw_jail.diff NOTES: o Apply the patch o cd /usr/src && make includes o rebuild your kernel (or just the ipfw module) o rebuild the ipfw userspace utility; Syntax: ipfw add count ip from any to any jail 1 "jail" takes a numeric argument, a jail ID. For those of you who dont know, jail IDs can be retrieved using the jls(8) utility. Input would be greatly appriciated. Thanks! -- Christian S.J. Peron [EMAIL PROTECTED] FreeBSD Committer ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ipfw cached ucred patch
I understand what you are saying. The only real other choice would be to copy out the entire cr_groups array. Do you know if this copy would be more expensive then the mutex lock/unlock associated with grabbing a reference to the ucred? -- Christian S.J. Peron [EMAIL PROTECTED] FreeBSD Committer ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ipfw cached ucred patch
Agreed, This was a concern for me as well, I was pretty carefull about managing the reference counts, I am currently testing this patch with a variety of rule types to check for ucred leaks. If/before this patch gets committed, I plan on doing another carefull scrutinization of the ipfw code to make sure there are no return, continues or breaks etc which could cause the ucred to be leaked. On 2 Jun 2004 Andre Oppermann wrote: > Christian S.J. Peron wrote: > >On 2 Jun 2004 Andre Oppermann wrote: > > > >>Christian S.J. Peron wrote: > >> > >>>All, > >>> > >>>Currently, when you have any rules which contain UID/GID > >>>constraints, ipfw will lock the pcb hash and do a lookup > >>>to find the pcb associated with that packet -- > >>>One for each constraint. > >>> > >>>I have written a patch in attempt to minimize the impact > >>>of PCB related lookups for these type of firewall rules. > >>> > >>>This patch will have the following effects on firewalls which > >>>contain UID/GID constraints: > >>> > >>>o Greatly reduce the locking contention associated > >>> with PCB lookups. > >>> > >>>o Increase the performance of firewall in general by making > >>> PCB lookups O(1) rather than O(n) (where n represents > >>> number of UID/GID constraints in the ruleset) > >>> > >>>It would be greatly appriciated if people who are running ipfw > >>>rules sets containing UID/GID constraints tested this patch > >>>and reported any success or failures. > >>> > >>>The patch can be downloaded from: > >>> > >>>http://people.freebsd.org/~csjp/ip_fw2_cached_ucred.patch > >> > >>You can optimize it even further by directly copying the uid/gid > >>from the ucred while you hold the INP_LOCK. There is no need to > >>hold on to the entire ucred. It should be sufficient to do the > >>ucred lookup only once per packet in the ipfw code. If you don't > >>find an INPCB for the packet you'll do a negative lookup for every > >>uid/gid rule. > > > >I thought about this to, however in order to implement GID contraints > >properly, we need to use groupmember(9) which requires the > >entire cr_groups[16] located in the ucred. I thought it was more > >elegant and cheaper to avoid the memcpy(sizeof(gid_t) * NGROUPS) > >and stick with the mutex. > > I see. Hmmm... Actually I'm only concerned that someone later > misses a crfree() call and starts to leak ucred structures. ipfw > is not the first place you are going to look for it. The more you > can keep together in one place the better it is. This kind > of error has already happend once with the initial implementation > of verrevpath in ifpw. The fuction did not correctly do the ref- > counting leading to a hefty rtentry leak. > > -- > Andre > -- Christian S.J. Peron [EMAIL PROTECTED] FreeBSD Committer ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ipfw cached ucred patch
On 2 Jun 2004 Andre Oppermann wrote: > Christian S.J. Peron wrote: > >All, > > > >Currently, when you have any rules which contain UID/GID > >constraints, ipfw will lock the pcb hash and do a lookup > >to find the pcb associated with that packet -- > >One for each constraint. > > > >I have written a patch in attempt to minimize the impact > >of PCB related lookups for these type of firewall rules. > > > >This patch will have the following effects on firewalls which > >contain UID/GID constraints: > > > > o Greatly reduce the locking contention associated > > with PCB lookups. > > > > o Increase the performance of firewall in general by making > > PCB lookups O(1) rather than O(n) (where n represents > > number of UID/GID constraints in the ruleset) > > > >It would be greatly appriciated if people who are running ipfw > >rules sets containing UID/GID constraints tested this patch > >and reported any success or failures. > > > >The patch can be downloaded from: > > > >http://people.freebsd.org/~csjp/ip_fw2_cached_ucred.patch > > You can optimize it even further by directly copying the uid/gid > from the ucred while you hold the INP_LOCK. There is no need to > hold on to the entire ucred. It should be sufficient to do the > ucred lookup only once per packet in the ipfw code. If you don't > find an INPCB for the packet you'll do a negative lookup for every > uid/gid rule. I thought about this to, however in order to implement GID contraints properly, we need to use groupmember(9) which requires the entire cr_groups[16] located in the ucred. I thought it was more elegant and cheaper to avoid the memcpy(sizeof(gid_t) * NGROUPS) and stick with the mutex. Anyone else have other ideas? -- Christian S.J. Peron [EMAIL PROTECTED] FreeBSD Committer ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
ipfw cached ucred patch
All, Currently, when you have any rules which contain UID/GID constraints, ipfw will lock the pcb hash and do a lookup to find the pcb associated with that packet -- One for each constraint. I have written a patch in attempt to minimize the impact of PCB related lookups for these type of firewall rules. This patch will have the following effects on firewalls which contain UID/GID constraints: o Greatly reduce the locking contention associated with PCB lookups. o Increase the performance of firewall in general by making PCB lookups O(1) rather than O(n) (where n represents number of UID/GID constraints in the ruleset) It would be greatly appriciated if people who are running ipfw rules sets containing UID/GID constraints tested this patch and reported any success or failures. The patch can be downloaded from: http://people.freebsd.org/~csjp/ip_fw2_cached_ucred.patch NOTE: It also appears that ip_output passes a reference to the PCB. Perhaps we can hold a reference to the ucred stored in that entry and do away with lookups on outgoing packets all-together? -- Christian S.J. Peron [EMAIL PROTECTED] FreeBSD Committer ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: [patch] Raw sockets in jails
I discovered the reason why traceroute breaks without -s with the most
recent patches I posted to the list.
When traceroute can not figure out what its source IP address is, it
generates a RTM_GET routing request through a routing socket and
extracts the source address of the route given the destination.
I have created a new set of patches, the only real difference is I modified
the routing code so that when it receives a RTM_GET request from a jailed
process, it re-defines the source address of the route so that it corresponds with
the prisons IP.
I have tested these patches and they appear to work, however
I ask for people to test and scrutinize these patches.
Feedback/comments are welcome.
Regards
Christian S.J. Peron
> new and improved patch <---
--- sys/kern/kern_jail.c.bakMon Apr 19 16:55:40 2004
+++ sys/kern/kern_jail.cMon Apr 19 17:56:03 2004
@@ -53,6 +53,11 @@
&jail_sysvipc_allowed, 0,
"Processes in jail can use System V IPC primitives");
+intjail_allow_raw_sockets = 0;
+SYSCTL_INT(_security_jail, OID_AUTO, allow_raw_sockets, CTLFLAG_RW,
+&jail_allow_raw_sockets, 0,
+"Prison root can create raw sockets");
+
/* allprison, lastprid, and prisoncount are protected by allprison_mtx. */
struct prisonlist allprison;
struct mtx allprison_mtx;
--- sys/net/rtsock.c.bakWed Apr 21 03:09:41 2004
+++ sys/net/rtsock.cThu Apr 22 17:37:42 2004
@@ -52,6 +52,8 @@
#include
#include
+#include
+
MALLOC_DEFINE(M_RTABLE, "routetbl", "routing tables");
/* NB: these are not modified */
@@ -289,6 +291,7 @@
int len, error = 0;
struct ifnet *ifp = 0;
struct ifaddr *ifa = 0;
+ struct sockaddr_in jail;
#define senderr(e) { error = e; goto flush;}
if (m == 0 || ((m->m_len < sizeof(long)) &&
@@ -400,8 +403,14 @@
ifp = rt->rt_ifp;
if (ifp) {
info.rti_info[RTAX_IFP] =
TAILQ_FIRST(&ifp->if_addrhead)->ifa_addr;
- info.rti_info[RTAX_IFA] =
- rt->rt_ifa->ifa_addr;
+ if (so->so_cred->cr_prison) {
+ jail.sin_family = PF_INET;
+ jail.sin_len = sizeof(jail);
+ jail.sin_addr.s_addr =
htonl(so->so_cred->cr_prison->pr_ip);
+ info.rti_info[RTAX_IFA] = (struct
sockaddr *)&jail;
+ } else
+ info.rti_info[RTAX_IFA] =
+ rt->rt_ifa->ifa_addr;
if (ifp->if_flags & IFF_POINTOPOINT)
info.rti_info[RTAX_BRD] =
rt->rt_ifa->ifa_dstaddr;
--- sys/netinet/raw_ip.c.b Mon Apr 19 16:23:57 2004
+++ sys/netinet/raw_ip.cThu Apr 22 18:30:42 2004
@@ -40,6 +40,7 @@
#include "opt_random_ip_id.h"
#include
+#include
#include
#include
#include
@@ -215,6 +216,10 @@
if (inp->inp_faddr.s_addr &&
inp->inp_faddr.s_addr != ip->ip_src.s_addr)
goto docontinue;
+ if (inp->inp_socket->so_cred->cr_prison)
+ if (htonl(inp->inp_socket->so_cred->cr_prison->pr_ip)
+ != ip->ip_dst.s_addr)
+ goto docontinue;
if (last) {
struct mbuf *n;
@@ -270,7 +275,11 @@
ip->ip_off = 0;
ip->ip_p = inp->inp_ip_p;
ip->ip_len = m->m_pkthdr.len;
- ip->ip_src = inp->inp_laddr;
+ if (inp->inp_socket->so_cred->cr_prison)
+ ip->ip_src.s_addr =
+ htonl(inp->inp_socket->so_cred->cr_prison->pr_ip);
+ else
+ ip->ip_src = inp->inp_laddr;
ip->ip_dst.s_addr = dst;
ip->ip_ttl = inp->inp_ip_ttl;
} else {
@@ -279,6 +288,13 @@
return(EMSGSIZE);
}
ip = mtod(m, struct ip *);
+ if (inp->inp_socket->so_cred->cr_prison) {
+ if (ip->ip_src.s_addr !=
+ htonl(inp->inp_socket->so_cred->cr_prison->pr_ip)) {
+ m_freem(m);
+ return (EPERM);
+ }
+
Re: [patch] Raw sockets in jails
Poul/group
The following patch makes raw sockets comply with prison IP addresses.
Some tools such as traceroute(8) may require that the prison IP address
be specified on the command line. I.E.
traceroute -s
Otherwise it might fail.
(because of this we may want to get rid of the
create_raw_sockets MIB all together).
Anyway, take a gander at it (testers feedback welcome):
Regards
Christian S.J. Peron
--- sys/netinet/raw_ip.c.b Mon Apr 19 16:23:57 2004
+++ sys/netinet/raw_ip.cTue Apr 20 19:43:30 2004
@@ -40,6 +40,7 @@
#include "opt_random_ip_id.h"
#include
+#include
#include
#include
#include
@@ -215,6 +216,11 @@
if (inp->inp_faddr.s_addr &&
inp->inp_faddr.s_addr != ip->ip_src.s_addr)
goto docontinue;
+ if (inp->inp_socket->so_cred->cr_prison) {
+ if (htonl(inp->inp_socket->so_cred->cr_prison->pr_ip)
+ != ip->ip_dst.s_addr)
+ goto docontinue;
+ }
if (last) {
struct mbuf *n;
@@ -270,7 +276,11 @@
ip->ip_off = 0;
ip->ip_p = inp->inp_ip_p;
ip->ip_len = m->m_pkthdr.len;
- ip->ip_src = inp->inp_laddr;
+ if (inp->inp_socket->so_cred->cr_prison)
+ ip->ip_src.s_addr =
+ htonl(inp->inp_socket->so_cred->cr_prison->pr_ip);
+ else
+ ip->ip_src = inp->inp_laddr;
ip->ip_dst.s_addr = dst;
ip->ip_ttl = inp->inp_ip_ttl;
} else {
@@ -279,6 +289,13 @@
return(EMSGSIZE);
}
ip = mtod(m, struct ip *);
+ if (inp->inp_socket->so_cred->cr_prison) {
+ if (ip->ip_src.s_addr !=
+ htonl(inp->inp_socket->so_cred->cr_prison->pr_ip)) {
+ m_freem(m);
+ return (EPERM);
+ }
+ }
/* don't allow both user specified and setsockopt options,
and don't allow packet length sizes that will crash */
if (((ip->ip_hl != (sizeof (*ip) >> 2))
@@ -505,6 +522,7 @@
}
}
+extern int jail_allow_raw_sockets;
u_long rip_sendspace = RIPSNDQ;
u_long rip_recvspace = RIPRCVQ;
@@ -527,7 +545,11 @@
INP_INFO_WUNLOCK(&ripcbinfo);
return EINVAL;
}
- if (td && (error = suser(td)) != 0) {
+ if (td && jailed(td->td_ucred) && !jail_allow_raw_sockets) {
+ INP_INFO_WUNLOCK(&ripcbinfo);
+ return (EPERM);
+ }
+ if (td && (error = suser_cred(td->td_ucred, PRISON_ROOT)) != 0) {
INP_INFO_WUNLOCK(&ripcbinfo);
return error;
}
@@ -626,6 +648,11 @@
if (nam->sa_len != sizeof(*addr))
return EINVAL;
+
+ if (td->td_ucred->cr_prison)
+ if (htonl(td->td_ucred->cr_prison->pr_ip)
+ != addr->sin_addr.s_addr)
+ return (EADDRNOTAVAIL);
if (TAILQ_EMPTY(&ifnet) ||
(addr->sin_family != AF_INET && addr->sin_family != AF_IMPLINK) ||
--- sys/kern/kern_jail.c.bakMon Apr 19 16:55:40 2004
+++ sys/kern/kern_jail.cMon Apr 19 17:56:03 2004
@@ -53,6 +53,11 @@
&jail_sysvipc_allowed, 0,
"Processes in jail can use System V IPC primitives");
+intjail_allow_raw_sockets = 0;
+SYSCTL_INT(_security_jail, OID_AUTO, allow_raw_sockets, CTLFLAG_RW,
+&jail_allow_raw_sockets, 0,
+"Prison root can create raw sockets");
+
/* allprison, lastprid, and prisoncount are protected by allprison_mtx. */
struct prisonlist allprison;
struct mtx allprison_mtx;
On 20 Apr 2004 Poul-Henning Kamp wrote:
> In message <[EMAIL PROTECTED]>, "Christian S.J. Peron" w
> rites:
> >
> >Although RAW sockets can be used when specifying the source
> >address of packets (defeating one of the aspects of the jail)
> >some people may find it usefull to use utilities like ping(8)
> >or traceroute(8) from inside jails.
> >
> >Enclosed is a patch I have written which gives you the option
> >of allowing prison-root to create raw sockets inside the prison,
> >so that programs various network debugging programs like ping
> >and traceroute etc can be used.
> >
> >This patch will create the security.jail.allow_raw_sockets sysctl
> >
[patch] Raw sockets in jails
Although RAW sockets can be used when specifying the source
address of packets (defeating one of the aspects of the jail)
some people may find it usefull to use utilities like ping(8)
or traceroute(8) from inside jails.
Enclosed is a patch I have written which gives you the option
of allowing prison-root to create raw sockets inside the prison,
so that programs various network debugging programs like ping
and traceroute etc can be used.
This patch will create the security.jail.allow_raw_sockets sysctl
MIB. I would appriciate any feed-back from testers
See PR #:
http://www.freebsd.org/cgi/query-pr.cgi?pr=65800
SNIP SNIP
--- sys/kern/kern_jail.c.bakMon Apr 19 16:55:40 2004
+++ sys/kern/kern_jail.cMon Apr 19 17:56:03 2004
@@ -53,6 +53,11 @@
&jail_sysvipc_allowed, 0,
"Processes in jail can use System V IPC primitives");
+intjail_allow_raw_sockets = 0;
+SYSCTL_INT(_security_jail, OID_AUTO, allow_raw_sockets, CTLFLAG_RW,
+&jail_allow_raw_sockets, 0,
+"Prison root can create raw sockets");
+
/* allprison, lastprid, and prisoncount are protected by allprison_mtx. */
struct prisonlist allprison;
struct mtx allprison_mtx;
--- sys/netinet/raw_ip.c.b Mon Apr 19 16:23:57 2004
+++ sys/netinet/raw_ip.cMon Apr 19 17:55:08 2004
@@ -40,6 +40,7 @@
#include "opt_random_ip_id.h"
#include
+#include
#include
#include
#include
@@ -505,6 +506,7 @@
}
}
+extern int jail_allow_raw_sockets;
u_long rip_sendspace = RIPSNDQ;
u_long rip_recvspace = RIPRCVQ;
@@ -527,7 +529,11 @@
INP_INFO_WUNLOCK(&ripcbinfo);
return EINVAL;
}
- if (td && (error = suser(td)) != 0) {
+ if (td && jailed(td->td_ucred) && !jail_allow_raw_sockets) {
+ INP_INFO_WUNLOCK(&ripcbinfo);
+ return (EPERM);
+ }
+ if (td && (error = suser_cred(td->td_ucred, PRISON_ROOT)) != 0) {
INP_INFO_WUNLOCK(&ripcbinfo);
return error;
}
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
