Re: api for sharing memory from kernel to userspace?
On Wed, May 19, 2004 at 05:29:07AM -0700, Alfred Perlstein wrote: +> I need to share about 100megs of memory between kernel and userspace. +> +> The memory can not be paged and should appear contig in the process's +> address space. Any suggestions? +> +> I need a way to either: +> map user memory into the kernel's address space. +> map kernel memory into the user's address space. +> +> I was looking at pmap_qenter() but it didn't see attractive because +> it's for "short term mappings", this mapping will exist for quite a +> while. In mapping kernel memory into user's address space I am interested as well for GEOM Gate and other evil projects. -- Pawel Jakub Dawidek http://www.FreeBSD.org [EMAIL PROTECTED] http://garage.freebsd.pl FreeBSD committer Am I Evil? Yes, I Am! pgpuGPDqfSSPA.pgp Description: PGP signature
Re: md(8) panic
On Thu, May 13, 2004 at 03:58:02PM +0300, Alex Lyashkov wrote: +> > This sector size is valid and shouldn't be rejected. +> > This patch works for me: +> > +> >http://people.freebsd.org/~pjd/patches/md.c.3.patch +> in patch +> +sc->nsect = (mdio->md_size * DEV_BSIZE) / sc->secsize; +> why not +> +sc->nsect = (mdio->md_size / sc->secsize ) * DEV_BSIZE ; +> +> for avoid posible overflow in mdio->md_size * DEV_BSIZE But your fix is incorrect: mdio->md_size = 20 sc->secsize = 512 In my version: sc->nsect = (20 * 512) / 512 = 20 In your version: sc->nsect = (20 / 512) * 512 = 0 -- Pawel Jakub Dawidek http://www.FreeBSD.org [EMAIL PROTECTED] http://garage.freebsd.pl FreeBSD committer Am I Evil? Yes, I Am! pgp0.pgp Description: PGP signature
Re: md(8) panic
On Wed, May 12, 2004 at 02:08:05PM +0100, Mike Bristow wrote: +> Hi, +> +> I am trying to access some ancient 5 1/4" floppies, with 256 byte +> sectors. Leaving aside the interesting hardware problems, the +> filesystem on these disks is (surprisingly enough) not supported on +> -CURRENT. While attempting to write one, I ran: +> +> # mdconfig -a -t malloc -S 256 -s 20 +> +> Thinking that this would give me some fake media to play with. Instead, +> it panics the box. +> +> This happens at line 809 of md.c version 1.222 which says: +> +> sc->nsect /= (sc->secsize / DEV_BSIZE); +> +> (where sc->secsize has been initialised to 256, as per +> my request). +> +> It would be easy to check for, and reject, such requests, but should +> md(8) allow people to create such devices? Or am I being silly in even +> asking for it? This sector size is valid and shouldn't be rejected. This patch works for me: http://people.freebsd.org/~pjd/patches/md.c.3.patch -- Pawel Jakub Dawidek http://www.FreeBSD.org [EMAIL PROTECTED] http://garage.freebsd.pl FreeBSD committer Am I Evil? Yes, I Am! pgp0.pgp Description: PGP signature
Re: [patch] Raw sockets in jails
On Tue, Apr 20, 2004 at 08:00:27PM +, Christian S.J. Peron wrote: +> 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): Looks very neat! I've merge your patch to my jail work (pjd_jail perforce branch) and changed it to be usable with my multiple ips stuff. I haven't reviewed nor tested it yet. -- Pawel Jakub Dawidek http://www.FreeBSD.org [EMAIL PROTECTED] http://garage.freebsd.pl FreeBSD committer Am I Evil? Yes, I Am! pgp0.pgp Description: PGP signature
Re: kernel modules programming: struct proc question
On Tue, Mar 16, 2004 at 07:39:56PM +0300, Roman Bogorodskiy wrote:
+> I hope it's a right place for kernel module programming related
+> questions, in another case I'd be glad if you point me to the right
+> maillist.
+>
+> So, my aim is to log every file opening in `/tmp' dir. I've wrote a simple
+> "syscall" module which replaces open(2) syscall. My new open(2) looks
+> like this:
Keep in mind, that there is no need to open file by giving its full path.
For example:
% cd /tmp
% cat ./foo
or:
% ln -s /tmp/foo ~/bar
% cat bar
--
Pawel Jakub Dawidek http://www.FreeBSD.org
[EMAIL PROTECTED] http://garage.freebsd.pl
FreeBSD committer Am I Evil? Yes, I Am!
pgp0.pgp
Description: PGP signature
Re: GEOM + Vinum
On Tue, Jan 20, 2004 at 07:47:02PM +0100, Lukas Ertl wrote: +> I think we should really get together on a separate mailing list - is it +> time for freebsd-geom@ yet? My proposal is [EMAIL PROTECTED] -- Pawel Jakub Dawidek [EMAIL PROTECTED] UNIX Systems Programmer/Administrator http://garage.freebsd.pl Am I Evil? Yes, I Am! http://cerber.sourceforge.net pgp0.pgp Description: PGP signature
Re: Future of RAIDFrame
On Sun, Jan 11, 2004 at 12:39:22PM +0100, Miguel Mendez wrote: +> >I started RAIDframe three years ago with the hope of bringing a proven +> >and extensible RAID stack to FreeBSD. Unfortunately, while it was made +> >to work pretty well on 4.x, it has never been viable on 5.x; it never +> >survived the introduction of GEOM and removal of the old disk layer. +> >I'm coming to the conclusion that I really don't have the time to work +> >on it in my spare time. Also, I've seen next to zero interest in it +> >from others, except for the occasional reminder that it doesn't work. +> +> William Carrel used to maintain a set of patches for RAIDframe on 4.x, +> were they ever committed? No? Why not? +> +> WRT lack of interest in RF. First, the 5.0 patches were horrible. That +> code was a mess to work with. Second, inertia. Most people with simple +> needs like mirroring and/or simple stripes were happy with good old +> ccd(4). Those who needed a full volume manager (which neither ccd nor RF +> claim to be) used vinum. People with VxVM experience feel at home with +> it. Unfortunately, vinum has its own set of issues as well. +> +> It's probably easier to write a set of GEOM classes from scratch than +> trying to shoehorn RF into GEOM. And that's what I'm doing. I'm working on one geom class (called for now geom_raid) which will support transformations like: concatenation, stripe (raid0), mirror (raid1), raid4 and raid5. The main goal is to prepare driver-independent configuration description that will fit to as many existing ondisk metadata formats as possible. So on one axis we got transformations and on another we got different types of on-disk metadata formats. Work is going forward, but slow, because of leak of time of course. For now I got concatenation and stripe working and I'm sitting on raid5 implementation right now. I know now that after raid5 will be implemented I'll have raid4 working as well (it fits to raid5 description). Last step (in transformations) will be raid1. It will be great if RF could be fixed and I'm still wondering to help with it or just focus on my geom_raid. RF implementation is complex and it will take some time to well understand it in first way. Reverse-engineering is time-consuming. I'm opened for suggestions. If Scott is sure and determined to reanimate RF and help me to understand RF I think I can help. -- Pawel Jakub Dawidek [EMAIL PROTECTED] UNIX Systems Programmer/Administrator http://garage.freebsd.pl Am I Evil? Yes, I Am! http://cerber.sourceforge.net pgp0.pgp Description: PGP signature
Re: MD(4) cleanups and unload lesson.
On Sun, Jan 11, 2004 at 12:48:56PM -0500, Robert Watson wrote: +> On Sun, 11 Jan 2004, Pawel Jakub Dawidek wrote: +> > With attached patch unloading md(4) module is possible. It also cleans +> > up big part of code according to style(9). +> +> Could you separate this into a functional diff and a style diff? There's +> a general preference to not combine them, as it means cvs diff between +> revisions isn't useful for identifying functional changes (i.e., reviewing +> for bugs when back-tracking, etc). Sure functional-only change is now here: http://garage.freebsd.pl/patches/md.c.patch and old patch is here: http://garage.freebsd.pl/patches/md.c.2.patch I haven't prepare style patch, because I wasn't sure against which version of md.c it should be (original or with functional change). -- Pawel Jakub Dawidek [EMAIL PROTECTED] UNIX Systems Programmer/Administrator http://garage.freebsd.pl Am I Evil? Yes, I Am! http://cerber.sourceforge.net pgp0.pgp Description: PGP signature
MD(4) cleanups and unload lesson.
Hello hackers...
With attached patch unloading md(4) module is possible.
It also cleans up big part of code according to style(9).
Patch is also avaliable at:
http://garage.freebsd.pl/patches/md.c.patch
--
Pawel Jakub Dawidek [EMAIL PROTECTED]
UNIX Systems Programmer/Administrator http://garage.freebsd.pl
Am I Evil? Yes, I Am! http://cerber.sourceforge.net
With this patch it is possible to unload md.ko module and it contains
a lot of cleanups (style(9)) and simplifies.
--- md.c.orig Sun Dec 28 11:12:22 2003
+++ md.cSun Jan 11 16:41:23 2004
@@ -98,7 +98,7 @@
static MALLOC_DEFINE(M_MD, "MD disk", "Memory Disk");
static MALLOC_DEFINE(M_MDSECT, "MD sectors", "Memory Disk Sectors");
-static int md_debug;
+static int md_debug = 0;
SYSCTL_INT(_debug, OID_AUTO, mddebug, CTLFLAG_RW, &md_debug, 0, "");
#if defined(MD_ROOT) && defined(MD_ROOT_SIZE)
@@ -107,13 +107,16 @@
static u_char end_mfs_root[] __unused = "MFS Filesystem had better STOP here";
#endif
-static g_init_t md_drvinit;
static int mdrootready;
static int mdunits;
static dev_t status_dev = 0;
+
static d_ioctl_t mdctlioctl;
+static g_init_t md_drvinit;
+static g_fini_t md_drvfini;
+static g_ctl_destroy_geom_t md_destroy_geom;
static struct cdevsw mdctl_cdevsw = {
.d_ioctl = mdctlioctl,
@@ -121,6 +124,14 @@
};
+struct g_class g_md_class = {
+ .name = "MD",
+ .init = md_drvinit,
+ .fini = md_drvfini,
+ .destroy_geom = md_destroy_geom,
+};
+
+
static LIST_HEAD(, md_s) md_softc_list = LIST_HEAD_INITIALIZER(&md_softc_list);
#define NINDIR (PAGE_SIZE / sizeof(uintptr_t))
@@ -168,7 +179,14 @@
vm_object_t object;
};
-static int mddestroy(struct md_s *sc, struct thread *td);
+struct md_tmp {
+ int unit;
+ int error;
+};
+
+
+static void mddestroy(struct md_s *sc);
+
static struct indir *
new_indir(u_int shift)
@@ -178,8 +196,8 @@
ip = malloc(sizeof *ip, M_MD, M_NOWAIT | M_ZERO);
if (ip == NULL)
return (NULL);
- ip->array = malloc(sizeof(uintptr_t) * NINDIR,
- M_MDSECT, M_NOWAIT | M_ZERO);
+ ip->array = malloc(sizeof(uintptr_t) * NINDIR, M_MDSECT,
+ M_NOWAIT | M_ZERO);
if (ip->array == NULL) {
free(ip, M_MD);
return (NULL);
@@ -240,8 +258,8 @@
* too much space for ip->array in here.
*/
ip = malloc(sizeof *ip, M_MD, M_WAITOK | M_ZERO);
- ip->array = malloc(sizeof(uintptr_t) * NINDIR,
- M_MDSECT, M_WAITOK | M_ZERO);
+ ip->array = malloc(sizeof(uintptr_t) * NINDIR, M_MDSECT,
+ M_WAITOK | M_ZERO);
ip->total = NINDIR;
ip->shift = layer * nshift;
return (ip);
@@ -292,7 +310,7 @@
cip = ip;
for (;;) {
lip[li++] = cip;
- if (cip->shift) {
+ if (cip->shift > 0) {
idx = (offset >> cip->shift) & NMASK;
up = cip->array[idx];
if (up != 0) {
@@ -335,12 +353,6 @@
return (0);
}
-
-struct g_class g_md_class = {
- .name = "MD",
- .init = md_drvinit,
-};
-
static int
g_md_access(struct g_provider *pp, int r, int w, int e)
{
@@ -352,11 +364,10 @@
r += pp->acr;
w += pp->acw;
e += pp->ace;
- if ((pp->acr + pp->acw + pp->ace) == 0 && (r + w + e) > 0) {
+ if ((pp->acr + pp->acw + pp->ace) == 0 && (r + w + e) > 0)
sc->opencount = 1;
- } else if ((pp->acr + pp->acw + pp->ace) > 0 && (r + w + e) == 0) {
+ else if ((pp->acr + pp->acw + pp->ace) > 0 && (r + w + e) == 0)
sc->opencount = 0;
- }
return (0);
}
@@ -376,9 +387,6 @@
wakeup(sc);
}
-DECLARE_GEOM_CLASS(g_md_class, g_md);
-
-
static int
mdstart_malloc(struct md_s *sc, struct bio *bp)
{
@@ -391,7 +399,7 @@
secno = bp->bio_pblkno;
dst = bp->bio_data;
error = 0;
- while (nsec--) {
+ while (nsec-- > 0) {
osp = s_read(sc->indir, secno);
if (bp->bio_cmd == BIO_DELETE) {
if (osp != 0)
@@ -406,7 +414,7 @@
bcopy((void *)osp, dst, sc->secsize);
osp = 0;
} else if (bp->bio_cmd == BIO_WRITE) {
- if (sc->flags & MD_COMPRESS) {
+ if ((sc->flags & MD_COMPRESS) != 0) {
uc = dst[0];
for (i = 1; i < sc->secsize; i++)
Re: Size-independent byte order swapping functions.
On Mon, Nov 24, 2003 at 05:13:08PM -0800, David Schultz wrote: +> On Mon, Nov 24, 2003, Pawel Jakub Dawidek wrote: +> > If one is using strictly defined types as uint8_t, uint16_t, int32_t, etc. +> > those macros are helpful IMHO, because futher value size changes does not +> > affects code for byte order managing. This also does not hit perfromance, +> > because this should be resolved at compile-time. +> +> Cool, looks useful. +> +> > I'm not sure if dedicated epanic() is the best way to implement out-of-range +> > errors prevention - the more handy solution should cause compile error. +> +> See CTASSERT. I've tried, but you can't use CTASSERT() inside (?:). -- Pawel Jakub Dawidek [EMAIL PROTECTED] UNIX Systems Programmer/Administrator http://garage.freebsd.pl Am I Evil? Yes, I Am! http://cerber.sourceforge.net pgp0.pgp Description: PGP signature
Size-independent byte order swapping functions.
Hello hackers...
Macros in attached patch are designed for doing life a little easier.
If one is using strictly defined types as uint8_t, uint16_t, int32_t, etc.
those macros are helpful IMHO, because futher value size changes does not
affects code for byte order managing. This also does not hit perfromance,
because this should be resolved at compile-time.
I'm not sure if dedicated epanic() is the best way to implement out-of-range
errors prevention - the more handy solution should cause compile error.
--
Pawel Jakub Dawidek [EMAIL PROTECTED]
UNIX Systems Programmer/Administrator http://garage.freebsd.pl
Am I Evil? Yes, I Am! http://cerber.sourceforge.net
--- endian.h.orig Sat Nov 22 13:15:40 2003
+++ endian.hMon Nov 24 10:57:02 2003
@@ -49,6 +49,46 @@
#endif
/*
+ * Size-independent byte order swapping functions.
+ */
+#ifdef _KERNEL
+#defineepanic(msg) _epanic(msg, __FILE__, __LINE__)
+/* New function, because panic(9) type is void and this is not enough. */
+static __inline int
+_epanic(const char *msg, const char *file, unsigned line)
+{
+
+ panic("%s:%u: %s", file, line, msg);
+ /* NOTREACHED */
+}
+#definebswap(x)(sizeof(x) == 1 ? (x) = (x) : \
+ (sizeof(x) == 2 ? bswap16(x) : \
+ (sizeof(x) == 4 ? bswap32(x) : \
+ (sizeof(x) == 8 ? bswap64(x) : \
+ epanic("out of range in bswap()")
+#definehtobe(x)(sizeof(x) == 1 ? (x) = (x) : \
+ (sizeof(x) == 2 ? htobe16(x) : \
+ (sizeof(x) == 4 ? htobe32(x) : \
+ (sizeof(x) == 8 ? htobe64(x) : \
+ epanic("out of range in htobe()")
+#definehtole(x)(sizeof(x) == 1 ? (x) = (x) : \
+ (sizeof(x) == 2 ? htole16(x) : \
+ (sizeof(x) == 4 ? htole32(x) : \
+ (sizeof(x) == 8 ? htole64(x) : \
+ epanic("out of range in htole()")
+#definebetoh(x)(sizeof(x) == 1 ? (x) = (x) : \
+ (sizeof(x) == 2 ? betoh16(x) : \
+ (sizeof(x) == 4 ? betoh32(x) : \
+ (sizeof(x) == 8 ? betoh64(x) : \
+ epanic("out of range in betoh()")
+#defineletoh(x)(sizeof(x) == 1 ? (x) = (x) : \
+ (sizeof(x) == 2 ? letoh16(x) : \
+ (sizeof(x) == 4 ? letoh32(x) : \
+ (sizeof(x) == 8 ? letoh64(x) : \
+ epanic("out of range in letoh()")
+#endif
+
+/*
* General byte order swapping functions.
*/
#definebswap16(x) __bswap16(x)
pgp0.pgp
Description: PGP signature
Re: "secure" file flag?
On Fri, Nov 21, 2003 at 12:41:05PM +0100, Dag-Erling Sm?rgrav wrote: +> > If this operation is able to fail (and of course it is) it should block +> > on unlink(2). +> +> FreeBSD is not DOS; unlink(2) does not actually remove the file. It +> is removed by the filesystem if the link count is zero when the vnode +> is released, which may be immediately after the unlink(2) call, or an +> indefinite amount of time later if the file was open at the time. I'm aware of this, but what we want to think over here is something like in-kernel 'rm -P'. So file will be overwriten even if it is opened and/or link count is grater than 0. That's why allowing link(2) operation for such files don't make much sens (the problem exists when there are hardlinks before "secure" flag is set). -- Pawel Jakub Dawidek [EMAIL PROTECTED] UNIX Systems Programmer/Administrator http://garage.freebsd.pl Am I Evil? Yes, I Am! http://cerber.sourceforge.net pgp0.pgp Description: PGP signature
Re: "secure" file flag?
On Thu, Nov 20, 2003 at 01:27:29PM -0800, Wes Peters wrote: +> On Tuesday 18 November 2003 16:31, Rayson Ho wrote: +> > I am wondering if it is useful to have a "secure" file flag?? +> > +> > The secure file flag will be set for files that contain sensitive +> > data. Then the OS will take special care when operating on those +> > "secure" files. +> > +> > e.g. when deleting a "secure" file, the OS will overwrite the file +> > with random data. +> +> Better to overwrite it with a more "secure" pattern. See ports/ +> sysutils/obliterate for references. It has been mentioned before that +> this could be done on in the kernel, obliterating blocks in the VM +> rather than zeroing them. I hadn't thought of applying at the file or +> filesystem level. +> +> > One advantage would be to have "secure" files in the same filesystem +> > as other normal files. +> > +> > Any one knows if FreeBSD has already implemented this?? +> +> The closest we have is the 'rm -P' command and the above-mentioned +> obliterate command. The overwrite pattern used in 'rm -P' is not +> likely to be effective against a dedicated inspection of the disk; the +> one in obliterate somewhat more so. +> +> This sounds like an interesting file flag. Would you expect the process +> to block on the unlink(2) call while the overwrite takes place, or for +> this to happen in a kernel thread? The former seems pretty straight- +> forward, hacking at ffs_blkfree. The latter I really wouldn't know how +> to begin without (a lot) more study. If this operation is able to fail (and of course it is) it should block on unlink(2). User has to be informed about status of operation like this one to give user a chance to do something else, performace isn't high-priority here, IMHO. Creating hard links to such file should be also forbiden (maybe only for non-owners). Another usefull thing will be posibility to pass flag to unlink(2) syscall to force "secure" removal (or "secure" removal in non-blocking mode as well). This will be more intuitive for programms that operate on many temporary files with sensitive data AND/OR allow setting this flag for directories. BTW. Poul-Henning Kamp proposed in his junior-kernel-hacker-todo-list mechanism that will provide zeroing all pages freed by 'special' process. This could be also implemented as file-flag (no modifications of source needed and this could be also used with close-source applications). Such "secure" flag for running process could be also implemented with multiple meanings: 1. All freed pages have to be zeroed. 2. All removed files have to be overwritten. 3. Umask for newly created files should be 0077. 4. "secure" flag for newly created files should be forced? 5. ... :) While phk is no more reading this list I'm CCing this mail to him. -- Pawel Jakub Dawidek [EMAIL PROTECTED] UNIX Systems Programmer/Administrator http://garage.freebsd.pl Am I Evil? Yes, I Am! http://cerber.sourceforge.net pgp0.pgp Description: PGP signature
Re: Questions on intercepting execve syscall
On Mon, Nov 17, 2003 at 11:02:10AM +0300, Samy Al Bahra wrote: +> > See http://www.enderunix.org/murat/linux_subexec/linux_subexec.c for a simple +> > example. +> +> This is 4.X specific (proc usage). I would just like to note that there is an +> execve symbol which you can reference in your code directly (rather than +> creating your own pointer for deinitialization). +> +> EX: +> -sysent[SYS_execve].sy_call = (sy_call_t *)oldexecve; +> +sysent[SYS_execve].sy_call = (sy_call_t *)execve; And if there are two modules that intercept execve(2)? Storing old value in dedicated pointer is correct. There still will be a problem when modules are loaded and unloaded in random order. Unload order have to be reverse load order, if not, invalid pointer (of module that was already unloaded) will be stored in sysent table. -- Pawel Jakub Dawidek [EMAIL PROTECTED] UNIX Systems Programmer/Administrator http://garage.freebsd.pl Am I Evil? Yes, I Am! http://cerber.sourceforge.net pgp0.pgp Description: PGP signature
Re: Multiple IPs in Jail
On Wed, Nov 12, 2003 at 10:01:23AM -0800, FB wrote: +> Before the patch was applied, the jail environment had no problem with dns. +> After the patch was applied however (and userland rebuilt both on host and +> jail), dns breaks in the jail environment. Basically, gethostbyname fails +> and h_errno is set to 2 - Host name lookup failure. the system is configured +> properly, since the only changes are to the kernel and the modified jail +> mechanism. Also interesting is that the failure is immediate, there is no +> timeout. Gethostbyname(3) always fails? You could try this patch againt recent -CURRENT, but I haven't added anything - for me gethostbyname(3) in jail works fine. http://garage.freebsd.pl/patches/mijail5_2.patch -- Pawel Jakub Dawidek [EMAIL PROTECTED] UNIX Systems Programmer/Administrator http://garage.freebsd.pl Am I Evil? Yes, I Am! http://cerber.sourceforge.net pgp0.pgp Description: PGP signature
Re: Multiple IPs in Jail
On Wed, Nov 12, 2003 at 10:01:23AM -0800, FB wrote: +> We patched mijail5 (http://garage.freebsd.pl/mijail.README) against +> RELENG_5_1. Most of the patch was successful with a little fuzz, except for +> a couple lines in jls which didn't patch due to cosmetic changes (easily +> fixed). +> +> Before the patch was applied, the jail environment had no problem with dns. +> After the patch was applied however (and userland rebuilt both on host and +> jail), dns breaks in the jail environment. Basically, gethostbyname fails +> and h_errno is set to 2 - Host name lookup failure. the system is configured +> properly, since the only changes are to the kernel and the modified jail +> mechanism. Also interesting is that the failure is immediate, there is no +> timeout. +> +> However, inbound/outbound TCP traffic is not effected. - we are able to ssh +> in/out of the jailed environment. +> I was testing outbound UDP traffic however - simple matter of binding a +> socket to send a packet to a remote host. +> +> Outside the jail, it worked fine. inside the jail, sendto failed with a +> EINVAL error. +> +> Any help on this topic would be much appreciated. I've many reports about DNS problems with my patch in jail, that's true. I can't promise, but I'll try to find some time in few days to track this problem down. -- Pawel Jakub Dawidek [EMAIL PROTECTED] UNIX Systems Programmer/Administrator http://garage.freebsd.pl Am I Evil? Yes, I Am! http://cerber.sourceforge.net pgp0.pgp Description: PGP signature
Re: geom_mirror implementation
On Wed, Nov 12, 2003 at 10:20:23AM +0100, Poul-Henning Kamp wrote: +> With regards to the larger "volume management picture" I will +> reiterate my position: +> +> Ideally I would prefer to have a set of primitive GEOM classes, +> GEOM_MIRROR, GEOM_STRIPE, GEOM_RAID5 etc and a separate set of +> "controller" GEOM classes, GEOM_VINUM, GEOM_RF, GEOM_VERITAS, to +> recognize the various "traditional LVM" metadata on the disk, and +> from that metadata stack the primitive modules. This would in the +> long term give us the maximal flexibility and ability with the +> least code. Actually I've done already GEOM_STRIPE class: http://garage.freebsd.pl/geom_stripe.tbz # stripe -v -s 65536 test /dev/da0 /dev/da1 /dev/da2 /dev/da3 Magic value stored on /dev/da0 Magic value stored on /dev/da1 Magic value stored on /dev/da2 Magic value stored on /dev/da3 # ls -l /dev/*.stripe /dev/test.stripe From my tests it is a bit faster than ccd(4). +> So realistically I expect that we will some day soon see a +> GEOM_RAIDFRAME (I gather Pawel is trying to help Scott on this). Not really. I've start planing something different (see my previous mail). -- Pawel Jakub Dawidek [EMAIL PROTECTED] UNIX Systems Programmer/Administrator http://garage.freebsd.pl Am I Evil? Yes, I Am! http://cerber.sourceforge.net pgp0.pgp Description: PGP signature
Re: geom_mirror implementation
On Sun, Nov 09, 2003 at 01:34:50PM -0800, David Schultz wrote: +> > > > I've played around with GEOM a bit and beefed up geom_mirror, which is +> > > > already in the tree but not built yet. +> > > > +> > > > You can find the patch at <http://mailbox.univie.ac.at/~le/geom.diff>. +> > > +> > > Hmm...I believe geom_mirror is supposed to be an example, and +> > > geom_ccd is supposed to be the production mirroring implementation. +> > > ccd does have its quirks, though... +> > +> > Last time I checked ccd needed to be manually reconfigured to run in +> > degraded mode and sync is not possible. In my book that's not good +> > enough for production. +> > +> > Furthermore it would be nice with a mirror implementation that +> > automatically syncs the mirror after an unclean shutdown. +> +> Yeah, RAID support in FreeBSD is in a rather sorry state right +> now. ccd(4) doesn't work with ATAng on my machine without causing +> panics and data corruption, raidframe is broken in -CURRENT, and +> vinum tends to lag behind changes and break. But that doesn't +> mean that the right solution is to add a *fourth* incompatible +> RAID implementation. If there's a good reason ccd(4) is harder to +> fix than geom_mirror, then you might want to talk to phk about +> rewriting geom_ccd based on geom_mirror. I believe scottl and phk +> have plans to fix raidframe, though, which would address a lot of +> the present limitations. Raidframe is going to be fixed by [EMAIL PROTECTED] This is a good news, but raidframe doesn't fit too good to GEOM infrastructure. GEOM gives flexibility which is duplicated by RF. I've start some work on more advance RAID implementation wich should fit to GEOM just fine. Every RAID level will be a different GEOM class, but with one configuration utility. All classes will share as many code as possible to be flexible in adding new RAID levels in futher. Strategy of choosing disks, failures handle, etc. should be also general. I want to provide support for many on-disk metadata formats if it will be possible. The bad news is that it is only a concept, I've only some initial code and project draft. I hope I'll find time to implement this. -- Pawel Jakub Dawidek [EMAIL PROTECTED] UNIX Systems Programmer/Administrator http://garage.freebsd.pl Am I Evil? Yes, I Am! http://cerber.sourceforge.net pgp0.pgp Description: PGP signature
Sysctls cleanup.
Helloi hackers...
I think this is more correct (but I haven't test it!).
I've started to implement labels for sysctls, but after thinking this
over again, I think this isn't really necessary.
--
Pawel Jakub Dawidek [EMAIL PROTECTED]
UNIX Systems Programmer/Administrator http://garage.freebsd.pl
Am I Evil? Yes, I Am! http://cerber.sourceforge.net
(c) 2003 Pawel Jakub Dawidek <[EMAIL PROTECTED]>
Patch against FreeBSD 5.1-CURRENT, kern.osreldate: 501110.
diff -upr /usr/src/sys/kern/kern_mac.c src/sys/kern/kern_mac.c
--- /usr/src/sys/kern/kern_mac.cTue Oct 14 21:15:22 2003
+++ src/sys/kern/kern_mac.c Thu Oct 16 04:45:37 2003
@@ -2961,8 +2961,8 @@ mac_check_system_swapoff(struct ucred *c
}
int
-mac_check_system_sysctl(struct ucred *cred, int *name, u_int namelen,
-void *old, size_t *oldlenp, int inkernel, void *new, size_t newlen)
+mac_check_system_sysctl(struct ucred *cred, struct sysctl_oid *oidp, void *arg1,
+int arg2, struct sysctl_req *req)
{
int error;
@@ -2973,8 +2973,7 @@ mac_check_system_sysctl(struct ucred *cr
if (!mac_enforce_system)
return (0);
- MAC_CHECK(check_system_sysctl, cred, name, namelen, old, oldlenp,
- inkernel, new, newlen);
+ MAC_CHECK(check_system_sysctl, cred, oidp, arg1, arg2, req);
return (error);
}
diff -upr /usr/src/sys/kern/kern_sysctl.c src/sys/kern/kern_sysctl.c
--- /usr/src/sys/kern/kern_sysctl.c Thu Oct 16 02:58:27 2003
+++ src/sys/kern/kern_sysctl.c Thu Oct 16 04:51:02 2003
@@ -1175,12 +1175,22 @@ sysctl_root(SYSCTL_HANDLER_ARGS)
if (!oid->oid_handler)
return EINVAL;
- if ((oid->oid_kind & CTLTYPE) == CTLTYPE_NODE)
- error = oid->oid_handler(oid, (int *)arg1 + indx, arg2 - indx,
- req);
- else
- error = oid->oid_handler(oid, oid->oid_arg1, oid->oid_arg2,
- req);
+ if ((oid->oid_kind & CTLTYPE) == CTLTYPE_NODE) {
+ (int *)arg1 += indx;
+ arg2 -= indx;
+ } else {
+ arg1 = oid->oid_arg1;
+ arg2 = oid->oid_arg2;
+ }
+
+#ifdef MAC
+ error = mac_check_system_sysctl(td->td_ucred, oid, arg1, arg2, req);
+ if (error != 0)
+ return (error);
+#endif
+
+ error = oid->oid_handler(oid, arg1, arg2, req);
+
return (error);
}
@@ -1271,15 +1281,6 @@ userland_sysctl(struct thread *td, int *
req.lock = REQ_LOCKED;
SYSCTL_LOCK();
-
-#ifdef MAC
- error = mac_check_system_sysctl(td->td_ucred, name, namelen, old,
- oldlenp, inkernel, new, newlen);
- if (error) {
- SYSCTL_UNLOCK();
- return (error);
- }
-#endif
do {
req2 = req;
diff -upr /usr/src/sys/security/mac_biba/mac_biba.c
src/sys/security/mac_biba/mac_biba.c
--- /usr/src/sys/security/mac_biba/mac_biba.c Thu Aug 21 16:34:54 2003
+++ src/sys/security/mac_biba/mac_biba.cThu Oct 16 04:34:56 2003
@@ -1941,8 +1941,8 @@ mac_biba_check_system_swapoff(struct ucr
}
static int
-mac_biba_check_system_sysctl(struct ucred *cred, int *name, u_int namelen,
-void *old, size_t *oldlenp, int inkernel, void *new, size_t newlen)
+mac_biba_check_system_sysctl(struct ucred *cred, struct sysctl_oid *oidp,
+void *arg1, int arg2, struct sysctl_req *req)
{
struct mac_biba *subj;
int error;
@@ -1953,16 +1953,10 @@ mac_biba_check_system_sysctl(struct ucre
subj = SLOT(&cred->cr_label);
/*
-* In general, treat sysctl variables as biba/high, but also
-* require privilege to change them, since they are a
-* communications channel between grades. Exempt MIB
-* queries from this due to undocmented sysctl magic.
-* XXXMAC: This probably requires some more review.
+* Treat sysctl variables without CTLFLAG_ANYBODY flag as
+* biba/high, but also require privilege to change them.
*/
- if (new != NULL) {
- if (namelen > 0 && name[0] == 0)
- return (0);
-
+ if (req->newptr != NULL && (oid->oid_kind & CTLFLAG_ANYBODY) == 0) {
if (!mac_biba_subject_dominate_high(subj))
return (EACCES);
diff -upr /usr/src/sys/security/mac_lomac/mac_lomac.c
src/sys/security/mac_lomac/mac_lomac.c
--- /usr/src/sys/security/mac_lomac/mac_lomac.c Thu Aug 21 20:07:52 2003
+++ src/sys/security/mac_lomac/mac_lomac.c Thu Oct 16 04:51:58 2003
@@ -2031,8 +2031,8 @@ mac_lomac_check_system_swapon(struct ucr
}
static int
-mac_lomac_check_system_sysctl(struct ucred *cred, int *name, u_int namelen,
-void *old, size_t *oldlenp, int inkernel, void *new, size_t newlen)
+mac_lomac_check_system_sysctl(struct ucred *cred, struct s
GEOM Gate.
Hello hackers... Ok, GEOM Gate is ready for testing. For those who don't know what it is, they can read README: http://garage.freebsd.pl/geom_gate.README and presentation from WIP/BSDCon03 session: http://garage.freebsd.pl/GEOM_Gate.pdf After compliation (cd geom_gate; make; make install) you should run regression tests: # regression/runtests.sh If everything will went ok you can play with GEOM Gate and report any bugs. I've spend some time to made GEOM Gate force-remove-safe so using '-f' option with ggc(8) should be always safe. Ah! Four manual pages are added, so feel free to read them first (gg(4), geom_gate(4), ggc(8), ggd(8)) http://garage.freebsd.pl/geom_gate.tbz Enjoy! -- Pawel Jakub Dawidek [EMAIL PROTECTED] UNIX Systems Programmer/Administrator http://garage.freebsd.pl Am I Evil? Yes, I Am! http://cerber.sourceforge.net pgp0.pgp Description: PGP signature
Re: Dynamic reads without locking.
On Thu, Oct 09, 2003 at 12:46:44PM -0700, Jeffrey Hsu wrote: +> This case (along with some other cases where locks of atomic reads +> are required) is covered in the paper as +> +> But, one case where locks would be required is if the field +> temporarily holds a value that no one else is supposed to see and +> the writer, operating with the lock held, will store a valid value +> before releasing his lock. In this case, both the writer and +> reader need to hold the lock before accessing this field. This isn't trivial problem for me, because: 1. Are we permitted to don't use locks while atomic read if it depends on writter, not on reader? If I'm adding variable modification and this modification have to be safe, I've to check every read of this variable and add locks everywhere. This order isn't quite correct. 2. If there is a chance for race while writting data not-atomically why we only permit atomic reads? In atomic vs. not-atomic read only probability of race is smaller, but it is still there. -- Pawel Jakub Dawidek [EMAIL PROTECTED] UNIX Systems Programmer/Administrator http://garage.freebsd.pl Am I Evil? Yes, I Am! http://cerber.sourceforge.net pgp0.pgp Description: PGP signature
Re: On-line judgment kernel module
On Thu, Oct 09, 2003 at 07:46:45AM +0300, earthman wrote: +> The idea is to deny all syscalls for specific +> process p. This is possible even without rewriting +> kernel by kernel module. +> +> Now I'm thinking how to do this. +> Possibly it would be easy to point p->sv_sysent +> to the structure that points sv_prepsyscall +> to some function that denies some system calls. +> (kill process, make some record in module about +> restricted call) +> But I don't understand how to cancel syscall +> out of those function. Maybe it's possible +> to change code parameter to something else. You may just try CerbNG: http://cerber.sourceforge.net It was presented on WIP session at BSDCon03, slides are here: http://garage.freebsd.pl/CerbNG.pdf 1.0-RC3 will be avaliable in near future. -- Pawel Jakub Dawidek [EMAIL PROTECTED] UNIX Systems Programmer/Administrator http://garage.freebsd.pl Am I Evil? Yes, I Am! http://cerber.sourceforge.net pgp0.pgp Description: PGP signature
Re: Dynamic reads without locking.
On Wed, Oct 08, 2003 at 11:51:06AM +0200, Harti Brandt wrote: +> You need to lock when reading if you insist on consistent data. Even a +> simple read may be non-atomic (this should be the case for 64bit +> operations on all our platforms). So you need to do +> +> mtx_lock(&foo_mtx); +> bar = foo; +> mtx_unlock(&foo_mtx); +> +> if foo is a datatype that is not guaranteed to be red atomically. For +> 8-bit data you should be safe without the lock on any architecture. I'm +> not sure for 16 and 32 bit, but for 64-bit you need the look for all +> our architectures, I think. But I'm not talking about non-atomic reads. What I'm want to show is that even atomic read (without lock) is dangerous in some cases. +> If you don't care about occasionally reading false data (for statistics or +> such stuff) you can go without the lock. I'm afraid that many developers thinks that atomic reads are always safe without locks (there are many such reads in sources). I hope I'm wrong. -- Pawel Jakub Dawidek [EMAIL PROTECTED] UNIX Systems Programmer/Administrator http://garage.freebsd.pl Am I Evil? Yes, I Am! http://cerber.sourceforge.net pgp0.pgp Description: PGP signature
Dynamic reads without locking.
Hello hackers... I'm wondering... Jeffrey Hsu was talking about this at BSDCon03. There is no need to lock data when we just made simple read, for example: mtx_lock(&foo_mtx); foo = 5; mtx_unlock(&foo_mtx); but only: bar = foo; IMHO this is quite dangerous. Let's see: thread1 thread2 mtx_lock(&foo_mtx); foo = data_from_user; bar = foo; foo &= MASK; mtx_unlock(&foo_mtx); In this case we have really dangerous race if data from user are safe only when we made 'and' operation on them. OR of course we can just store wrong value in 'bar' and this could be case of different problems. So I'm not sure now if I understand everything well. We can't just say 'We never split such writes. We always do: foo = (data_from_user & MASK)', because author of some 3rd party kernel module will be sure that when he locks writes to some variable this operation is safe and he could split such writes and in kernel could be dynamic read without lock. Does this make any sense? -- Pawel Jakub Dawidek [EMAIL PROTECTED] UNIX Systems Programmer/Administrator http://garage.freebsd.pl Am I Evil? Yes, I Am! http://cerber.sourceforge.net pgp0.pgp Description: PGP signature
Re: user malloc from kernel
On Mon, Sep 29, 2003 at 06:56:13PM +0300, Peter Pentchev wrote: +> I mean, won't the application's memory manager attempt to allocate the +> next chunk of memory right over the region that you have stolen with +> this brk(2) invocation? Thus, when the application tries to write into +> its newly-allocated memory, it will overwrite the data that the kernel +> has placed there, and any attempt to access the kernel's data later will +> fail in wonderfully unpredictable ways :) I'm not sure if newly allocated memory will overwrite memory allocated in kernel, but for sure process is able to write to this memory. Sometime ago I proposed model which will allow to remove all copyin(9) calls and many copyout(9), but I'm not so skilled in VM to implement it. -- Pawel Jakub Dawidek [EMAIL PROTECTED] UNIX Systems Programmer/Administrator http://garage.freebsd.pl Am I Evil? Yes, I Am! http://cerber.sourceforge.net pgp0.pgp Description: PGP signature
Re: user malloc from kernel
On Mon, Sep 29, 2003 at 05:22:47PM +0300, earthman wrote: +> how to allocate some memory chunk +> in user space memory from kernel code? +> how to do it correctly? Here you got sample kernel module which do this: http://garage.freebsd.pl/usmalloc.tgz http://garage.freebsd.pl/usmalloc.README -- Pawel Jakub Dawidek [EMAIL PROTECTED] UNIX Systems Programmer/Administrator http://garage.freebsd.pl Am I Evil? Yes, I Am! http://cerber.sourceforge.net pgp0.pgp Description: PGP signature
GEOM Gate status.
Hello hackers... I've spend some time working on GEOM Gate, so... Cache was implemented, but only for reading (cache for write requests isn't good idea here, IMHO). Many workers can be used now. This will help to split requests. Requests are queued and always worker with minimal number of pending requests is choosen. Workers can be added at run-time with '-r' option. ggd(8) use now NFS-like exports file. Sample entries: 192.168.0.3 RD /dev/acd0 192.168.0.4 RW /test.img 192.168.0.5 RW /dev/ad0s1a I've also wrote some manual pages: - gg(4), - geom_gate(4) (exists, but isn't finished yet), - ggc(8), - ggd(8). There are few sysctls that could help in performace and memory consumption tuning and more to come. TODO. Errors handling needs more work. Maybe UDP (for now transport is done via TCP). Per-device sysctls created automatically. Regression tests. Performance benchmarks. GEOM Gate is avaliable at: http://garage.freebsd.pl/geom_gate.tbz http://garage.freebsd.pl/geom_gate.README See you all at BSDCon 2003!:) -- Pawel Jakub Dawidek [EMAIL PROTECTED] UNIX Systems Programmer/Administrator http://garage.freebsd.pl Am I Evil? Yes, I Am! http://cerber.sourceforge.net pgp0.pgp Description: PGP signature
Safe rename(2)/link(2)/unlink(2).
Hello hackers... Sometime ago I've proposed secure versions of syscalls from subject on IRC. I've decide to describe them here more precisely. Now all those 3 syscalls aren't safe from race-conditions point of view. That's for sure. Other syscalls are implemented in two variants, for example chmod(2) and fchmod(2). Ok, let's go. int funlink(int fd, const char *path); int flink(int fd, const char *name1, const char *name2); int frename(int fd, const char *from, const char *to); How it all works... In funlink(2) fd is used to compare vnode of opened file and file that should be removed. It doesn't really matters if fd represents exactly the same file or only its hard link, because we only want to be sure that file wasn't removed and new (different) file wasn't created before our call to funlink(2). In flink(2) and frename(2) situation is very simlar. The only race here is: thread 1thread 2 create file 'a' link 'a' to 'b' fd = open file 'a' remove file 'a' link 'b' to 'a' funlink(fd, 'a') But this isn't problematic at all, isn't it?:) This operation will fail if 'thread 2' will create new file 'a' instead of creating hard link to file 'b'. Comments? -- Pawel Jakub Dawidek [EMAIL PROTECTED] UNIX Systems Programmer/Administrator http://garage.freebsd.pl Am I Evil? Yes, I Am! http://cerber.sourceforge.net pgp0.pgp Description: PGP signature
Re: Inode Operations
On Sat, Aug 23, 2003 at 07:54:45PM -0700, Tim Kientzle wrote: +> I'm working on some archiving programs and need to (for various +> reasons) keep track of a very large number of files so that I +> can revisit them at the end of the operation. For example, +> on extract, I need to set directory access times and permissions +> after the complete extract is finished, which requires me to +> record every created directory. (No, there is no way around +> this short of re-scanning the entire archive a second +> time, which is impractical at best.) +> +> Right now, I'm storing the full pathname of each such +> file, but that is taking up a lot of memory, so I'm looking +> for a more compact approach. It occurred to me that +> the device number/inode (as returned by stat(2)) is another +> way to uniquely identify a file. As it turns out, I need to +> stat() everything anyway, so collecting such identifiers is easy. +> But, I can't find any system calls that actually use this information. +> +> Question: Are there any system calls that allow you to +> access/modify a file based only on the device number/inode number? Check getfh(2)/fhopen(2) syscall if you are root. -- Pawel Jakub Dawidek [EMAIL PROTECTED] UNIX Systems Programmer/Administrator http://garage.freebsd.pl Am I Evil? Yes, I Am! http://cerber.sourceforge.net pgp0.pgp Description: PGP signature
Re: [future patch] dropping user privileges on demand
On Fri, Aug 22, 2003 at 05:40:23PM +1000, Peter Jeremy wrote: +> Unless 'syscall' can be evaluated at compile time, this approach adds +> overhead whereever it is used - and the overhead gets worse as the +> number of system calls in the set increases. A particular problem is +> that the overhead is worst for system calls that aren't caught (in the +> above, the overhead for open() is trivial but write() would need to go +> through each of the tests). A bit-vector provides constant overhead +> but it's still fairly expensive unless the relevant parts of the vector +> are already cached. You are wrong. In CerbNG, you decide in rules which syscalls should be catched and which not. And syscalls like read(2) and write(2) are never catched, because it is just useless. The most expensive policy in syscalls catching is openssh - it is monitoring 21 syscalls, but most of policies use only few syscalls. Of course there is overhead, but I haven't heard about security feature that speeds up system. The only thing we can do, is to decrease overhead. -- Pawel Jakub Dawidek [EMAIL PROTECTED] UNIX Systems Programmer/Administrator http://garage.freebsd.pl Am I Evil? Yes, I Am! http://cerber.sourceforge.net pgp0.pgp Description: PGP signature
Re: [future patch] dropping user privileges on demand
On Thu, Aug 21, 2003 at 01:09:15PM -0400, ari wrote:
+> [...] 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. [...]
In CerbNG you only need to write a macro like:
#define DROP_FS_CREATION() \
if (syscall == SYS_open || syscall == SYS_mkfifo || \
syscall == SYS_bind || syscall == SYS_link || ...) {\
return (EPERM); \
}
+> 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.
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.
--
Pawel Jakub Dawidek [EMAIL PROTECTED]
UNIX Systems Programmer/Administrator http://garage.freebsd.pl
Am I Evil? Yes, I Am! http://cerber.sourceforge.net
pgp0.pgp
Description: PGP signature
Re: [future patch] dropping user privileges on demand
On Thu, Aug 21, 2003 at 01:58:54AM -0500, Dan Nelson wrote: +> 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'm planing to do so in next CerbNG version, as well as allow jailed-roots to load rules that affects only jailed-processes. -- Pawel Jakub Dawidek [EMAIL PROTECTED] UNIX Systems Programmer/Administrator http://garage.freebsd.pl Am I Evil? Yes, I Am! http://cerber.sourceforge.net pgp0.pgp Description: PGP signature
Re: [future patch] dropping user privileges on demand
On Thu, Aug 21, 2003 at 08:50:28AM -0400, ari wrote: +> 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. 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. -- Pawel Jakub Dawidek [EMAIL PROTECTED] UNIX Systems Programmer/Administrator http://garage.freebsd.pl Am I Evil? Yes, I Am! http://cerber.sourceforge.net pgp0.pgp Description: PGP signature
Re: [future patch] dropping user privileges on demand
On Thu, Aug 21, 2003 at 12:39:00AM -0700, Kris Kennaway wrote: +> > 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). +> +> Exercise for the reader: find a situation where the failure to perform +> a syscall that normally succeeds, leads to privilege escalation :-) The answer is: Every network daemon. If you could compromise it, you get local access. -- Pawel Jakub Dawidek [EMAIL PROTECTED] UNIX Systems Programmer/Administrator http://garage.freebsd.pl Am I Evil? Yes, I Am! http://cerber.sourceforge.net pgp0.pgp Description: PGP signature
Re: GEOM Gate.
On Sat, Aug 16, 2003 at 08:50:30PM -0500, Dan Nelson wrote: +> What kind of hardware were you using? 2.5MB/sec NFS sounds abysmal. I don't think it is a hardware problem. Run this test on 5.1-CURRENT with: options INVARIANTS options INVARIANT_SUPPORT options WITNESS and without any network and NFS optimization. And this test was: for write: % dd if=/dev/zero /mnt/nfs/test bs=128k count=500 for read: % dd if=/mnt/nfs/test /dev/null bs=128k count=500 -- Pawel Jakub Dawidek [EMAIL PROTECTED] UNIX Systems Programmer/Administrator http://garage.freebsd.pl Am I Evil? Yes, I Am! http://cerber.sourceforge.net pgp0.pgp Description: PGP signature
Re: GEOM Gate.
On Fri, Aug 15, 2003 at 11:53:11AM -0400, Robert Watson wrote: +> That said, I think the geom gate stuff looks very cool :-). You might be +> able to run some interesting performance numbers comparing NFS and UFS +> over a remote block device. Ok. After last geom gate optimizations I'm ready to show some tests. NFS read: 2539890 bytes/sec NFS write: 2668428 bytes/sec GG read file: 5791796 bytes/sec (file was exported) GG write file: 4071411 bytes/sec (file was exported) GG read device: 4635277 bytes/sec (disk device was exported) GG write device: I wasn't able to test This was tested over 100Mbit/s network without any network tuning. -- Pawel Jakub Dawidek [EMAIL PROTECTED] UNIX Systems Programmer/Administrator http://garage.freebsd.pl Am I Evil? Yes, I Am! http://cerber.sourceforge.net pgp0.pgp Description: PGP signature
Re: GEOM Gate.
On Thu, Aug 14, 2003 at 09:48:57PM +0200, Attila Nagy wrote: +> Bruce M Simpson wrote: +> >Whatever next? PCI-over-IP? +> Collecting cheap on board serial lines to make a big terminal server +> makes sense to me :) +> +> BTW, Pawel's stuff would be even more interesting if it would be +> possible to mount the same filesystem on more than one machines. It'll be, but probably in read-write mode on one machine and read-only mode on rest machines, because you don't export file systems here, but disk devices. -- Pawel Jakub Dawidek [EMAIL PROTECTED] UNIX Systems Programmer/Administrator http://garage.freebsd.pl Am I Evil? Yes, I Am! http://cerber.sourceforge.net pgp0.pgp Description: PGP signature
Re: GEOM Gate.
On Fri, Aug 15, 2003 at 06:44:14PM +1000, Peter Jeremy wrote: +> >But there are two problems: +> >1. Device major numbers. +> +> I don't see this as a problem - you do the name to major/minor mapping +> on the remote system. All that goes across the network is the device +> name (filename in /dev). This is the same way that NFS works. The +> device major number is just an easy way for the kernel to map a device +> name onto the device-specific functions to access the physical +> hardware - this only needs to occur on the server. Hmm, I was thinking about something like this: # devaccess 192.168.0.2 host1 # ls -l /dev/host1 And 'devaccess' command will call some kernel mechanism to create new devices, but all those devices are defined in this way: [...] .d_open = std_open, .d_close = std_close, .d_ioctl = std_ioctl, .d_maj =?? [...] And std_open()/std_close()/std_ioctl() are functions that only pass requests to userland daemon, which forwards them to remote host and back. +> >2. Handle network errors. +> +> I think the easiest way is just to pass them back to the application. +> This does mean that an application would get unexpected network-related +> errors, but there's no obvious alternative. Or translate all of them to EIO. -- Pawel Jakub Dawidek [EMAIL PROTECTED] UNIX Systems Programmer/Administrator http://garage.freebsd.pl Am I Evil? Yes, I Am! http://cerber.sourceforge.net pgp0.pgp Description: PGP signature
Re: GEOM Gate.
On Thu, Aug 14, 2003 at 09:52:25PM +0400, Buckie wrote: +> BTW, QNX had this for a long time, it's called QNet in there. Allows +> transparently to mount or use anything in /dev. Even a soundcard! I think this isn't really hard to implement. But there are two problems: 1. Device major numbers. 2. Handle network errors. -- Pawel Jakub Dawidek [EMAIL PROTECTED] UNIX Systems Programmer/Administrator http://garage.freebsd.pl Am I Evil? Yes, I Am! http://cerber.sourceforge.net pgp0.pgp Description: PGP signature
GEOM Gate.
Hello hackers... I've done something what will be called GEOM Gate. This software provide disk devices mounting through the network. http://garage.freebsd.pl/geom_gate.tbz Installation is quite trivial: # tar -jvxf geom_gate.tbz # cd geom_gate # make # make install For example we got two machine: 'client' and 'server' and we want to mount device /dev/ad0s1a from 'server' machine on 'client' machine. server# ggd -f /dev/ad0s1a client# kldload geom_gate client# ggc -a -h 'server' -s sizeof(/dev/ad0s1a) -u 5 client# mount /dev/gg5 /mnt/foo And that's all. Of course we can also export files and treat them as devices: server# truncate -s 256M test.img server# ggd -f ./test.img -p 1234 client# ggc -a -h 'server' -p 1234 -s 256M -u 6 client# newfs -O2 -U /dev/gg6 client# mount /dev/gg6 /mnt/bar This isn't finished yet, so it also isn't bugs free. For example don't try to run client and server stuff on this same machine, this could case a deadlock. Comments, etc. are of course welcome. -- Pawel Jakub Dawidek [EMAIL PROTECTED] UNIX Systems Programmer/Administrator http://garage.freebsd.pl Am I Evil? Yes, I Am! http://cerber.sourceforge.net pgp0.pgp Description: PGP signature
Re: VM problem...
On Mon, Jul 21, 2003 at 08:51:19PM +0100, Bruce M Simpson wrote: Matt, Bruce, thanks! I've track it down. Yes, those read-only pages was reused. So now I'm putting them on list before syscall is called, and after syscall is executed I free memory for non-execve syscalls and mark entries from list as VM_PROT_ALL for execve(). I'll play in the future with vm_map_delete() maybe those pages are removable in safe way. But why memory allocator, that is responsible for finding pages for stack don't check their permissions? -- Pawel Jakub Dawidek [EMAIL PROTECTED] UNIX Systems Programmer/Administrator http://garage.freebsd.pl Am I Evil? Yes, I Am! http://cerber.sourceforge.net pgp0.pgp Description: PGP signature
Re: VM problem...
On Mon, Jul 21, 2003 at 12:32:19PM -0700, Matthew Dillon wrote: +> Hmm. Well, when a process forks the vm_map_entry's fork along with +> it. The underlying VM objects remain shared but become copy-on-write. Yes, but I mean while execve(), not fork(). Before execve() is called map got for example 65 pages in its vm map. One of this page is marked as read-only. After execve() process vm map got only 2 pages. I susspect, that pages from before execve() are floating around. And this read-only pages also and maybe it can be reused for stack? If not, what happend with them? -- Pawel Jakub Dawidek [EMAIL PROTECTED] UNIX Systems Programmer/Administrator http://garage.freebsd.pl Am I Evil? Yes, I Am! http://cerber.sourceforge.net pgp0.pgp Description: PGP signature
Re: VM problem...
On Mon, Jul 21, 2003 at 12:03:59PM -0700, Matthew Dillon wrote: +> Hmm. Is the VM object properly sized? Any attempt to fault-in data +> beyond a VM object's EOF, regardless of how you set the map_entry +> permissions, will seg fault or bus fault. I'm allocationg memory with obreak() function (so vm_map_find() function is used to find space). But if I try to allocate size (and size is small), obreak() will allocate more memory. end = vm->vm_daddr + ctob(vm->vm_dsize); obreak(vm, end + size); vm_map_protect(&vm->vm_map, end, end + size, VM_PROT_READ); And vm_map_protect() will create new map entry (it should, right?) with entry->start = end and entry->end = end + size. But what happend with those entries when execve() is called? Because process' map catched before execve() doesn't exists after execve() is called. So maybe those entries (with VM_PROT_READ) are reused somehow? THANKS! -- Pawel Jakub Dawidek [EMAIL PROTECTED] UNIX Systems Programmer/Administrator http://garage.freebsd.pl Am I Evil? Yes, I Am! http://cerber.sourceforge.net pgp0.pgp Description: PGP signature
Re: Communications kernel -> userland
On Mon, Jul 21, 2003 at 02:20:40PM -0400, Robert Watson wrote: +> For one of our research projects, here at NAI, we did a fair amount of +> userland network code prototyping. We started out with IPDIVERT, then +> pushed down to BPF using a partial network stack in userspace. We've +> found it's a lot easier on competent network developers who are unfamiliar +> with the FreeBSD kernel code, not to mention easier on debugging. We +> never got so far on that project as to do shared memory between the kernel +> and userspace, but I know that that's been done by at least a couple of +> companies at various points to reduce copying and context switch costs for +> userspace test frameworks. One of the things I'd really like to see if +> some decent "throw packets between kernel and userspace" primitive bits, +> such that the kernel has a useful and logical way to expose buffer data +> into directly mapped user pages, and an appropriate notification and +> management system to reuse memory, etc. Something that looks a bit like +> the relationship between kernel device drivers and devices when it comes +> to DMA management. Do you know if any such framework exists? +> (Specifically targetted at exposing network packets...) (Ideally not +> requiring privilege in the user process, nor involving nasty integrity or +> confidentiality problems :-) It will be cool to have something like this: mark(vm_map_t map, vm_offset_t start, vm_offset_t end); unmark(vm_map_t map, vm_offset_t start, vm_offset_t end); It will be used instead of copyin()/copyout() functions. For example syscall is marking some range with mark() function. For now on this range isn't accessable from userland. If process will try to write to this page, page is copied (copy-on-write). If this page will be modified by kernel it will be marked as MODIFIED. Now when syscall will call unmark() on this range we could get two scenarious: 1. Page is marked as MODIFIED (by kernel) so userland copy of this page (if it exists of course) is destroyed and this page will be putted in its place. This is replacement for copyin() and then copyout() or just copyout().. 2. Page isn't marked as MODIFIED, so kernel version of page is destroyed (is there is userland version). This is replacement for just copyin(). There could be other ways. Thread/process could be locked if it is trying to access memory marked with mark() function. And this, I think, don't hit performance, because this happends really rarely. So maybe it is better to lock thread for a moment instead of doplicating page, but I don't think so. -- Pawel Jakub Dawidek [EMAIL PROTECTED] UNIX Systems Programmer/Administrator http://garage.freebsd.pl Am I Evil? Yes, I Am! http://cerber.sourceforge.net pgp0.pgp Description: PGP signature
Re: VM problem...
On Mon, Jul 21, 2003 at 01:57:59AM +0200, Pawel Jakub Dawidek wrote: +> So as you can see I'm listing every entry that isn't writable. +> This function is called when process is killed by kernel with SIGBUS. +> It shows me that only this region isn't writable: +> +> ENTRY:: 0-0xbfc0 (0:0) Of course it isn't it. I've changed all map entries protection to VM_PROT_ALL and now on SIGBUS (in trapsignal()) every listed entry got protection = VM_PROT_ALL and max_protection = VM_PROT_ALL. So what the hell is going on here?:S I'm not a VM expert so please help me to track this down. I'm trying real hard to made this by myself for a week now. Is there posibility that there is some map entry that isn't on process p->p_vmspace->vm_map? Maybe some shared entry not connected with his map, but which should be accessable for this process? If trap is generated, because of illegal access nothing is changed with map entries before trapsignal() is called? I'm really confused, so if someone could find few minutes, hour or short day:) to help me track this down, I'll be really grateful. -- Pawel Jakub Dawidek [EMAIL PROTECTED] UNIX Systems Programmer/Administrator http://garage.freebsd.pl Am I Evil? Yes, I Am! http://cerber.sourceforge.net pgp0.pgp Description: PGP signature
VM problem...
Hello hackers...
I'll try to describe my problem carefully, maybe there will be someone
who will be able to help me with this.
Problem: Strage 'Bus errors'.
What I'm doing?
I allocate memory in process' vmspace with my version of obreak function.
It is quite simlar to those from /sys/vm/vm_unix.c.
end = vm->vm_daddr + ctob(vm->vm_dsize);
my_obreak(vm, end + size);
Now I'm marking newly allocated range as read-only (it is my version
of vm_map_protect() function, but is really simlar to):
my_vm_protect(&vm->vm_map, end, end + size, VM_PROT_READ);
Now execve() for this process is called, so I can't remove this memory,
because this range isn't in process' vmspace anymore (I believe, that
it should be removed, by VM or execve()).
Process forks and now something happends in child and parent quits with
SIGBUS. I've add some debug to trapsignal() from /sys/kern/kern_sig.c.
Now I'm able to list every entry from process' vm_map with this function:
void
show_entries(struct proc *p)
{
vm_map_entry_t entry;
entry = p->p_vmspace->vm_map.hint;
do {
if ((entry->max_protection & VM_PROT_WRITE) == 0) {
printf("ENTRY:%u: %p-%p (%d:%d)\n", p->p_pid,
(void *)entry->start, (void *)entry->end,
entry->protection, entry->max_protection);
}
entry = entry->next;
} while (entry != p->p_vmspace->vm_map.hint);
}
So as you can see I'm listing every entry that isn't writable.
This function is called when process is killed by kernel with SIGBUS.
It shows me that only this region isn't writable:
ENTRY:: 0-0xbfc0 (0:0)
Ok! But all my allocations starts with 0x8xxx.
But core file that I get tells me, that:
Cannot access memory at address 0xbfbffc20.
If I change VM_PROT_READ to VM_PROT_ALL when calling my_vm_protect()
everything is correct. There is no SIGBUS, but this region: 0-0xbfc0
is still marked as not writable (and I really believe that it should be:)).
So how my allocations and read-only stuff interact with those bus errors?
PS. I'm CC-ing this to Matt Dillon also. I know he is quite busy now,
but maybe he will be able to track this down.
PS2. I'm talking about FreeBSD 4.x here.
--
Pawel Jakub Dawidek [EMAIL PROTECTED]
UNIX Systems Programmer/Administrator http://garage.freebsd.pl
Am I Evil? Yes, I Am! http://cerber.sourceforge.net
pgp0.pgp
Description: PGP signature
Re: Communications kernel -> userland
On Sat, Jul 19, 2003 at 09:47:08AM +0200, Pawel Jakub Dawidek wrote: +> On Fri, Jul 18, 2003 at 03:47:05PM -0400, Marc Ramirez wrote: +> +> I have a remote datastore that I want to present as a filesystem. There +> +> are two parts to this: fetching raw data over the network, and doing some +> +> processing on the data. For purposes of maintainability, I'd like to do +> +> as little of this as possible inside the kernel, so I've currently got a +> +> daemon to fetch and process the data, and then pipes it over a socket to +> +> the kernel FS layer. +> +> Your choices are: +> - device, +> - sysctl, +> - syscall. +> +> You need to think about what you exactly need and which options will be +> the best. Creating new syscall isn't good idea, creating device is more +> complicated than sysctl, but of course it's up to you and your needs. Hmm, there is a chance that I've reverse direction:) But if you don't use kevent/kqueue you need to tell kernel that you want to read data. For example exporting logs from kernel to userland (to syslogd) is via device /dev/klog. -- Pawel Jakub Dawidek [EMAIL PROTECTED] UNIX Systems Programmer/Administrator http://garage.freebsd.pl Am I Evil? Yes, I Am! http://cerber.sourceforge.net pgp0.pgp Description: PGP signature
Re: Communications kernel -> userland
On Fri, Jul 18, 2003 at 03:47:05PM -0400, Marc Ramirez wrote: +> I have a remote datastore that I want to present as a filesystem. There +> are two parts to this: fetching raw data over the network, and doing some +> processing on the data. For purposes of maintainability, I'd like to do +> as little of this as possible inside the kernel, so I've currently got a +> daemon to fetch and process the data, and then pipes it over a socket to +> the kernel FS layer. Your choices are: - device, - sysctl, - syscall. You need to think about what you exactly need and which options will be the best. Creating new syscall isn't good idea, creating device is more complicated than sysctl, but of course it's up to you and your needs. -- Pawel Jakub Dawidek [EMAIL PROTECTED] UNIX Systems Programmer/Administrator http://garage.freebsd.pl Am I Evil? Yes, I Am! http://cerber.sourceforge.net pgp0.pgp Description: PGP signature
Re: running 5.1-RELEASE with no procfs mounted (lockups?)
On Fri, Jul 18, 2003 at 01:45:34AM -0700, Terry Lambert wrote: +> > +> trussRelies on the event model of procfs; there have been some +> > +> initial patches and discussion of migrating truss to ptrace() but +> > +> I don't think we have anything very usable yet. I'd be happy to +> > +> be corrected on this. :-) +> > +> > Hmm, why to change this behaviour? Is there any functionality that +> > ktrace(1) doesn't provide? +> +> It can interactively run in another window, giving you realtime +> updates on what's happening up to the point of a kernel crash. +> With ktrace, you are relatively screwed. Hmm, you're talking about: # ktrace -p # kdump -l ? +> Another good example is that it dump out information that ktrace +> can't, because of where it synchronizes. Some people recently +> have been seeing "EAGAIN" when they haven't expected it, with +> the process exiting immediately after that, with no real clue +> as to where in the code it's happening (e.g. which system call); +> truss will show this, if run in another terminal window, but +> ktrace will not (yes, I know it should; it doesn't. If you can't +> reconcile this with how you think ktrace should work, then fix it). Note, that I'm not for removing truss(1). I'm only saying that in most cases ktrace(1) is sufficient. You can always mount procfs in those special situations. -- Pawel Jakub Dawidek [EMAIL PROTECTED] UNIX Systems Programmer/Administrator http://garage.freebsd.pl Am I Evil? Yes, I Am! http://cerber.sourceforge.net ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: complicated downgrade
On Fri, Jul 18, 2003 at 12:12:48PM +0300, Valentin Nechayev wrote:
This is really hard task...
+>for D in /bin /sbin /etc /boot /usr/bin /usr/sbin /usr/lib /usr/libexec \
+> /usr/libdata /usr/share /usr/local /var/db
+>do
+>mv ${D} ${D}5
+>mv ${D}4 {D}
+>done
Here is a race:)
# mv /bin /bin5
# mv /bin4 /bin
mv: Command not found.
:)
--
Pawel Jakub Dawidek [EMAIL PROTECTED]
UNIX Systems Programmer/Administrator http://garage.freebsd.pl
Am I Evil? Yes, I Am! http://cerber.sourceforge.net
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: running 5.1-RELEASE with no procfs mounted (lockups?)
On Thu, Jul 17, 2003 at 01:01:11PM -0400, Robert Watson wrote: +> Most system functionality that relied on procfs has been rewritten to rely +> on other mechanisms. In general, I advise against running procfs--it's +> interesting, but conceptually it's very risky. If you look at the history +> of security advisories on systems that supported procfs (FreeBSD, Linux, +> Solaris), you'll get a sense of why: procfs represents processes as files, +> and the semantics of processes and of files are very different. For +> example, with processes, there are notions of revoked access; processes +> are reused to hold several programs often running with different +> credentials. +> +> The behavior I'm aware of that currently relies on procfs and has not yet +> been adapted to use ptrace() or sysctl() are: +> +> ps -e Relies on groping around in the address space of each +> process to display environmental variables. I've prepare patch for this: http://garage.freebsd.pl/patches/ps-e.patch +> trussRelies on the event model of procfs; there have been some +> initial patches and discussion of migrating truss to ptrace() but +> I don't think we have anything very usable yet. I'd be happy to +> be corrected on this. :-) Hmm, why to change this behaviour? Is there any functionality that ktrace(1) doesn't provide? IMHO made ugly hacks just to made truss(1) (for years procfs-dependent) working without procfs is a bad idea. It could only display some friendly message that procfs isn't mounted instead of: truss: cannot open /proc/25217/mem: No such file or directory truss: cannot open /proc/curproc/mem: No such file or directory -- Pawel Jakub Dawidek [EMAIL PROTECTED] UNIX Systems Programmer/Administrator http://garage.freebsd.pl Am I Evil? Yes, I Am! http://cerber.sourceforge.net pgp0.pgp Description: PGP signature
Re: Jail sysctls and new flags to sysctls.
On Thu, Jul 17, 2003 at 06:07:48PM +0200, Pawel Jakub Dawidek wrote: +> Patch add also two flags to sysctls: +> CTLFLAG_USERINV - sysctl is invisible for unprivileged users +> CTLFLAG_JAILINV - sysctl is invisible in jail environment Note, that things like security.bsd.unprivileged_read_msgbuf (protecting two sysctls from reading) could be made in general way with those flags and any sysctl or sysctls node could be protected with them. -- Pawel Jakub Dawidek [EMAIL PROTECTED] UNIX Systems Programmer/Administrator http://garage.freebsd.pl Am I Evil? Yes, I Am! http://cerber.sourceforge.net pgp0.pgp Description: PGP signature
Jail sysctls and new flags to sysctls.
Hello hackers. I've prepare a quite handy patch. This patch adds sysctls for every jails. Sysctls are created automatically when jail is created and destroyed when jail is removed. If jail with ID 3 is created we got new sysctls: security.jails.3.path (RD) security.jails.3.host (RW) security.jails.3.ip (RD) security.jails.3.securelevel (RW) Patch add also two flags to sysctls: CTLFLAG_USERINV - sysctl is invisible for unprivileged users CTLFLAG_JAILINV - sysctl is invisible in jail environment So newly created sysctls aren't visable in jails. it also provides changing host of running jail and its securelevel. Jail's securelevel could be even downgraded if it stay bigger or equal to main securelevel. With this functionality jls(8) could be rewritten to use this and xprison struct could be removed from kernel. Patch against FreeBSD 5.1-CURRENT, kern.osreldate: 501102. It is avaliable at: http://garage.freebsd.pl/patches/jail_sysctls.patch -- Pawel Jakub Dawidek [EMAIL PROTECTED] UNIX Systems Programmer/Administrator http://garage.freebsd.pl Am I Evil? Yes, I Am! http://cerber.sourceforge.net pgp0.pgp Description: PGP signature
Re: Bug in VM pages protection handling.
On Tue, Jul 15, 2003 at 04:06:18AM -0500, Alan L. Cox wrote:
+> Could you post a pointer to the kernel module's source code?
It is hard to reproduce, you need majordomo for this:)
Here is discussion about this:
https://sourceforge.net/mailarchive/forum.php?thread_id=2722479&forum_id=7642
And here is procedure that should handle everything:
# cd /usr/ports/mail/majordomo
# make install clean
# cd /tmp
# cvs -d:pserver:[EMAIL PROTECTED]:/cvsroot/cerb-ng co -D "July 11, 2003"
cerb-ng
# cd cerb-ng
# make; make install
# kldload cerb
# /sbin/cbctl -f /path/to/majordomo-test.cb
and:
# echo test | /usr/local/majordomo/wrapper resend -l test-l test-l-outgoing
Here you should have 'Bus error'.
Policy majordomo-test.cb is attached. Look into logs for PIDs of processes
that was monitored by cerb, they got read-only pages and look at PID
of process exiting with SIGBUS.
I've spend two days(?) on tracking this down in cerb, so good luck!
PS. Note that we're talking about FreeBSD 4.x here.
--
Pawel Jakub Dawidek [EMAIL PROTECTED]
UNIX Systems Programmer/Administrator http://garage.freebsd.pl
Am I Evil? Yes, I Am! http://cerber.sourceforge.net
#include "addons.cbh"
beginrules
REGISTER("majorodomo-test")
ADD_SYSCALL(SYS_execve);
if (syscall == SYS_execve && ruid > 0) {
log(LOG_INFO, "PROCESS: %s PID=%u, ruid=%u, euid=%u", pname, pid, ruid,
euid);
/*
* Because here we're using syscall argument (arg[0]) new page
* page will be allocated for this argument and this page
* will be marked as read-only.
*/
log(LOG_INFO, "ARG[0]: %s", arg[0]);
return call();
}
endrules
pgp0.pgp
Description: PGP signature
Re: Bug in VM pages protection handling.
On Tue, Jul 15, 2003 at 01:05:01AM -0700, David Schultz wrote: +> So let me see if I've got the sequence of events straight: +> +> 1) The process forks +> +> 2) The child makes a system call that results in the creation of a +>new read-only map entry. +> +> 3) The parent calls mmap() (for example) to create a read-write +>map entry with the same virtual address. +> +> 4) Somehow the parent's permissions end up being read-only, not +>read-write, and the parent dies. +> +> Is this correct? If so, this doesn't sound like a problem with +> vm_map_protect(), but rather with your handling of map entry +> sharing. My first inclination, as a non-expert, would be that +> you're not taking MAP_ENTRY_NEEDS_COPY into account. This is an +> optimization that allows two processes to share map entries until +> a COW fault is taken in one of them. This speeds up fork(2) +> greatly because VM objects are not allocated unnecessarily. Not exactly. Every page was is marked by cerb as read-only is also allocated by cerb in process' vmspace, so IMHO such situation shouldn't occur. We got something like this: 1. The process forks. 2. New pages are allocated in child's vmspace and are marked as read-only. 3. I don't know exactly what happends with child, but parent dies. I've solve this problem by marking those pages back to VM_PROT_ALL after syscall is done. Is there a chance that parent reuse those pages somehow? Or those pages aren't removed and if parent want to allocate some memory he gets read-only page? But I don't think so... -- Pawel Jakub Dawidek [EMAIL PROTECTED] UNIX Systems Programmer/Administrator http://garage.freebsd.pl Am I Evil? Yes, I Am! http://cerber.sourceforge.net pgp0.pgp Description: PGP signature
Re: Sysctls and mutexes.
On Sun, Jun 29, 2003 at 09:12:11AM +0200, Pawel Jakub Dawidek wrote: +> I want to discuss two things about sysctls. [...] +> 2. Secound thing. I'm wondering if there is no need to and one more field +>to those macros: mutex that protects given value. Then standard functions +>sysctl_handle_*() could use those mutexes when accessing to those values. +> +> Look at sysctl creation in /sys/dev/sound/pcm/mixer.c in function +> mixer_hwvol_init() or at sysctls in /sys/kern/kern_jail.c and many others +> as I susspect. +> +> There is no need to break anything. We could create for now new macros: +> SYSCTL_ADD_INT_MTX(), etc. that will create int sysctl, but with information +> about its mutex. We should also teach sysctl_handle_int and friends how to +> lock those mutexes and that they should ignore locking when this field is NULL. Ok, I've prepared a patch for this: http://www.freebsd.org/cgi/query-pr.cgi?pr=54439 Could someone review it, please? -- Pawel Jakub Dawidek [EMAIL PROTECTED] UNIX Systems Programmer/Administrator http://garage.freebsd.pl Am I Evil? Yes, I Am! http://cerber.sourceforge.net pgp0.pgp Description: PGP signature
Re: Bug in VM pages protection handling.
On Sat, Jul 12, 2003 at 03:57:18PM -0500, Alan L. Cox wrote:
+> > I've just send PR for this:
+> >
+> > http://www.freebsd.org/cgi/query-pr.cgi?pr=54418
+> >
+> > I'll be greatful if somebody could review, commit and MFC it
+> > as soon as possible. I need to hold CerbNG next release until
+> > it will be fixed.
+> >
+>
+> As I've said in private e-mail, this is not a bug. You're really asking
+> for a change in "specification". Reductions in max_protection have had
+> permanent effect since the late 1980's.
You've also asked my in private mail why I need this, I'll answer here.
I need this to protect syscall arguments that I'm checking in CerbNG.
If I need to check an argument I've to be sure that kernel will check
exactly that same argument (here is ugly race).
So what I do is memory allocaton in process' vmspace, copy argument
there, mark newly allocated pages as read-only and call original
syscall with new pointer(s). Those pages are freed after that and
everything will be correct, but somebody has reported me about
'bus error'. I've track this problem for two days. It occurs for
majordomo, when perl is trying to execute something, nevermind.
Pages are marked as read-only for child process, but parent
process is killed with SIGBUS signal. I don't mees with this parent
process at all, but it looks they're sharing some memory or some
pages/map is mirrored (copy-on-write mechanism?) with VM_PROT_READ
protection.
Of course I could rewrite vm_map_protect() function locally and use my
version (I hate such hacks, but if there is no other way...), but for me
it is strange. Is there something that depends on this or proposed
patch breaks anything? Why specification says that?
Ok, I don't want to provoke specification breakage, I was just thinking
that this was a bug, so PR could be closed, sorry.
PS1. Maybe you (or anyone) have better solution for syscall arguments
protecting to avoid this race?
PS2. Where could I find FreeBSD's VM specification? Or maybe I should
look for posix VM spcification?
--
Pawel Jakub Dawidek [EMAIL PROTECTED]
UNIX Systems Programmer/Administrator http://garage.freebsd.pl
Am I Evil? Yes, I Am! http://cerber.sourceforge.net
pgp0.pgp
Description: PGP signature
Bug in VM pages protection handling.
Hello hackers... I've just send PR for this: http://www.freebsd.org/cgi/query-pr.cgi?pr=54418 I'll be greatful if somebody could review, commit and MFC it as soon as possible. I need to hold CerbNG next release until it will be fixed. Thanks! -- Pawel Jakub Dawidek [EMAIL PROTECTED] UNIX Systems Programmer/Administrator http://garage.freebsd.pl Am I Evil? Yes, I Am! http://cerber.sourceforge.net pgp0.pgp Description: PGP signature
setattr() system call (task from phk TODO list).
Hello.
I think I got patch for setattr() syscall (attached as setattr.patch)
and it works fine, but there is a problem in ufs_setattr().
It looks like ufs_setattr() will don't handle property changes of many
file attibutes, because there is many places where it can modify some
attributes, but return with error, because next change will fail.
For now there is also no chance to change flags to '[su]chg'/'[su]appnd'
and other attributes in one call of ufs_setattr(), because flags are
changed first and other modifications aren't permitted because of that.
If we put flags changing code at the end, there will be no chance to
change other attributes when flags are '[su]chg' or '[su]appnd'.
So I'm sending also patch for UFS that allow other attributes changes
when before or after setattr() there is/will be no [su](chg|appnd)
flags (patch attached: ufs_setattr.patch). It isn't the best way.
The best why will be made a copy of inode struct go through changes
and copy it back only if everything succeeded. This cost performance
of course, so...
PS. This syscall will be quite usefull in tar(1) I think.
--
Pawel Jakub Dawidek [EMAIL PROTECTED]
UNIX Systems Programmer/Administrator http://garage.freebsd.pl
Am I Evil? Yes, I Am! http://cerber.sourceforge.net
diff -ur /usr/src/sys/kern/syscalls.master src/sys/kern/syscalls.master
--- /usr/src/sys/kern/syscalls.master Sat Jul 5 16:54:11 2003
+++ src/sys/kern/syscalls.masterSat Jul 5 16:54:05 2003
@@ -637,6 +637,9 @@
int attrnamespace, void *data, size_t nbytes); }
439STD BSD { ssize_t extattr_list_link(const char *path, \
int attrnamespace, void *data, size_t nbytes); }
+440STD BSD { int setattr(char *path, struct stat *sb, int op); }
+441STD BSD { int lsetattr(char *path, struct stat *sb, int op); }
+442STD BSD { int fsetattr(int fd, struct stat *sb, int op); }
; Please copy any additions and changes to the following compatability tables:
; sys/ia64/ia32/syscalls.master (take a best guess)
diff -ur /usr/src/sys/kern/vfs_syscalls.c src/sys/kern/vfs_syscalls.c
--- /usr/src/sys/kern/vfs_syscalls.cTue Jul 1 11:29:38 2003
+++ src/sys/kern/vfs_syscalls.c Sat Jul 5 21:12:23 2003
@@ -1940,48 +1940,254 @@
return (error);
}
-/*
- * Common implementation code for chflags() and fchflags().
- */
static int
-setfflags(td, vp, flags)
- struct thread *td;
- struct vnode *vp;
- int flags;
+setfattr(struct thread *td, struct vnode *vp, struct stat *sb, u_int op,
+int locked)
{
- int error;
struct mount *mp;
struct vattr vattr;
+ int error;
- /*
-* Prevent non-root users from setting flags on devices. When
-* a device is reused, users can retain ownership of the device
-* if they are allowed to set flags and programs assume that
-* chown can't fail when done as root.
-*/
- if (vp->v_type == VCHR || vp->v_type == VBLK) {
- error = suser_cred(td->td_ucred, PRISON_ROOT);
- if (error)
+ if ((op & SA_OP_ALL) == 0)
+ return (0);
+
+ if ((op & SA_OP_FLAGS) != 0) {
+ /*
+* Prevent non-root users from setting flags on devices. When
+* a device is reused, users can retain ownership of the device
+* if they are allowed to set flags and programs assume that
+* chown can't fail when done as root.
+*/
+ if (vp->v_type == VCHR || vp->v_type == VBLK) {
+ error = suser_cred(td->td_ucred, PRISON_ROOT);
+ if (error)
+ return (error);
+ }
+ }
+
+ if (!locked) {
+ if ((error = vn_start_write(vp, &mp, V_WAIT | PCATCH)) != 0)
return (error);
+ VOP_LEASE(vp, td, td->td_ucred, LEASE_WRITE);
+ vn_lock(vp, LK_EXCLUSIVE | LK_RETRY, td);
}
- if ((error = vn_start_write(vp, &mp, V_WAIT | PCATCH)) != 0)
- return (error);
- VOP_LEASE(vp, td, td->td_ucred, LEASE_WRITE);
- vn_lock(vp, LK_EXCLUSIVE | LK_RETRY, td);
VATTR_NULL(&vattr);
- vattr.va_flags = flags;
+
+ if ((op & SA_OP_FLAGS) != 0) {
+ vattr.va_flags = sb->st_flags;
#ifdef MAC
- error = mac_check_vnode_setflags(td->td_ucred, vp, vattr.va_flags);
- if (error == 0)
+ error = mac_check_vnode_setflags(td->td_ucred, vp,
+ vattr.va_flags);
+ if (error != 0)
+ goto fail;
#endif
- error = VOP_SETATTR(vp, &vattr, td->td_ucred, td);
- VOP_UNLOCK(
Re: hints on shell string expansion ?
On Mon, Jul 07, 2003 at 12:46:26AM -0700, Luigi Rizzo wrote: +> I am writing a script to generate ipfw test cases, and as +> part of the script i need to generate 'actions' which can be either +> one or more, e.g. [...] +> actions="allow 'deny log' 'pipe 10'" +> for act in $actions ; do +> echo "add $act ip from 1.2.3.4 to 5.6.7.8" +> done +> +> I have tried to play tricks with quotes and backquotes, backslashes, +> eval, etc. but no methods helped. Any ideas ? Maybe just: IFS='#' actions="allow#deny log#pipe 10" for act in $actions; do echo "add $act ip from 1.2.3.4 to 5.6.7.8" done -- Pawel Jakub Dawidek [EMAIL PROTECTED] UNIX Systems Programmer/Administrator http://garage.freebsd.pl Am I Evil? Yes, I Am! http://cerber.sourceforge.net ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Sysctls and mutexes.
Hello. I want to discuss two things about sysctls. 1. If there is need to use M_WAITOK when allocating memory? Every SYSCTL_ADD_* macro returns pointer that could be tested if it isn't NULL (when malloc(9) failed). I'm talking about dynamic sysctls. 2. Secound thing. I'm wondering if there is no need to and one more field to those macros: mutex that protects given value. Then standard functions sysctl_handle_*() could use those mutexes when accessing to those values. Look at sysctl creation in /sys/dev/sound/pcm/mixer.c in function mixer_hwvol_init() or at sysctls in /sys/kern/kern_jail.c and many others as I susspect. There is no need to break anything. We could create for now new macros: SYSCTL_ADD_INT_MTX(), etc. that will create int sysctl, but with information about its mutex. We should also teach sysctl_handle_int and friends how to lock those mutexes and that they should ignore locking when this field is NULL. -- Pawel Jakub Dawidek [EMAIL PROTECTED] UNIX Systems Programmer/Administrator http://garage.freebsd.pl Am I Evil? Yes, I Am! http://cerber.sourceforge.net pgp0.pgp Description: PGP signature
Re: [Cerb-list] CerbNG v1.0-RC2 is now avaliable!
On Wed, Jun 11, 2003 at 07:20:26PM +0200, clemens fischer wrote: +> > We are proudly announce that CerbNG-1.0 Release Candidate 2 is now +> > avaliable. +> +> congratulations! may i suggest to always include the CVS tag of any +> release announced here? i just tried to make(1) the CVS HEAD on my +> freebsd-4.8, but this failed the compilation. Could you please send any compilation output on cerb mailing list? Maybe it's just because cerb releases don't needed bison and source from CVS head branch does. -- Pawel Jakub Dawidek [EMAIL PROTECTED] UNIX Systems Programmer/Administrator http://garage.freebsd.pl Am I Evil? Yes, I Am! http://cerber.sourceforge.net pgp0.pgp Description: PGP signature
CerbNG v1.0-RC2 is now avaliable!
Hello! We are proudly announce that CerbNG-1.0 Release Candidate 2 is now avaliable. There are many changes from RC1 (many new functionalities, some bug fixes, new interesting policies, new regression tests and more). It seems that CerbNG is stable for now, so we hope that the next version is going to be final 1.0 series release. We count on feedback from FreeBSD community in founding bugs (if there are any:)), contributing new policies, comments (critism as well) and any help. We want to thank all people that helped us create better, more functional and stable CerbNG. As we all know motivation gives us strength for hard work and in the open-source world motivation is provided by interest and feedback from community. We hope that when 1.0-RELEASE is avaliable, we will be able to present RC1 of CerbNG for FreeBSD 5.x. CerbNG can be found at: http://cerber.sourceforge.net http://sourceforge.net/projects/cerber/ Release notes are at: http://cerber.sourceforge.net/CerbNG-1.0-RC2-RELNOTES.txt Always up to date (snapshot from HEAD) policies are avaliable at: http://cerber.sourceforge.net/policies/ We would also like to invite you to subscribe cerb mailing lists. Enjoy!! Pawel Jakub Dawidek, Slawek Zak. -- Pawel Jakub Dawidek [EMAIL PROTECTED] UNIX Systems Programmer/Administrator http://garage.freebsd.pl Am I Evil? Yes, I Am! http://cerber.sourceforge.net pgp0.pgp Description: PGP signature
Re: trimming of chroot jail path in df(1)
On Mon, Jun 02, 2003 at 04:02:48PM +0300, Alexandr Kovalenko wrote: +> I've found module jailfsstat: +> +> http://garage.freebsd.pl/jailfsstat.tgz +> +> which task is that process in jail can see only file systems mounted +> inside of jail. Ok, jailfsstat module was fixed and could be found here: http://garage.freebsd.pl/jailfsstat.tbz Thanks Alexandr! -- Pawel Jakub Dawidek [EMAIL PROTECTED] UNIX Systems Programmer/Administrator http://garage.freebsd.pl Am I Evil? Yes, I Am! http://cerber.sourceforge.net pgp0.pgp Description: PGP signature
Re: Forged subscriptions and the troll.
On Sun, Jun 01, 2003 at 04:46:10PM +0100, Mark Murray wrote: +> We are currently being attacked by an individual who is attempting +> to mass-subscribe our lists to other mailing lists. +> +> PLEASE DO NOT RESPOND TO ANY OF THIS MAIL! I am taking care of it. +> +> Thank you for your co-operation. :-) Maybe is time to disallow posting for non-members on selected lists? -- Pawel Jakub Dawidek [EMAIL PROTECTED] UNIX Systems Programmer/Administrator http://garage.freebsd.pl Am I Evil? Yes, I Am! http://cerber.sourceforge.net pgp0.pgp Description: PGP signature
Re: trimming of chroot jail path in df(1)
On Mon, Jun 02, 2003 at 04:02:48PM +0300, Alexandr Kovalenko wrote: +> I've found module jailfsstat: +> +> http://garage.freebsd.pl/jailfsstat.tgz +> +> which task is that process in jail can see only file systems mounted +> inside of jail. +> +> It works somehow incorrect and I would like to ask you for an URL of +> FreeBSD's vfs implementation documentation. Somebody has raported that there is off-by-one error somewhere, but it wasn't critical AFAIK. Have you found some other incorrect behaviour? If yes, I could always fix it in my free time. -- Pawel Jakub Dawidek [EMAIL PROTECTED] UNIX Systems Programmer/Administrator http://garage.freebsd.pl Am I Evil? Yes, I Am! http://cerber.sourceforge.net pgp0.pgp Description: PGP signature
Locking, locking...
Hello hackers...
I need advice how to handle with one locking problem.
For example I got some list with some values. This list could be
modified by any process. I want to get values from this list and
copy them to allocated table. But how to count number of needed
fields?
mtx_lock(&mtx_list_lock);
n = 0;
SLIST_FOREACH(elem, &list_head, l_next) {
n++;
}
mtx_unlock(&mtx_list_lock);
tab = malloc(n * sizeof(something), M_TEMP, M_WAITOK);
mtx_lock(&mtx_list_lock);
[...]
As we all knew size of list could be changed when we were in malloc().
Of course we could check list size again after malloc() and mtx_lock(),
but what to do when it was changed? Recall memory allocation?
If size of this list depends on every process there is a chance to DoS
such piece of code. Return an error? Not always it is possible.
IMHO there should be malloc() version that could be called under lock.
Malloc() M_NOWAIT could be called in such scenario?
How do you handle with situations like this?
Thanks!
--
Pawel Jakub Dawidek [EMAIL PROTECTED]
UNIX Systems Programmer/Administrator http://garage.freebsd.pl
Am I Evil? Yes, I Am! http://cerber.sourceforge.net
pgp0.pgp
Description: PGP signature
Re: jail && (ping && traceroute)
On Fri, May 30, 2003 at 05:35:42PM +0300, Alexandr Kovalenko wrote: +> I have 2 questions: +> +> - where in code should I search for icmp socket binding prohibition in +>jail?; +> - what bad consequences will appear if I remove those checks and +>prohibition?. This is nasty to allow all jailed process to open RAW sockets. You can use CerbNG to allow only selected jailed process to open RAW socket. General policy is here: http://cerber.sourceforge.net/policies/jailed-icmp.cb but you can easly rewrite it to allow only selected process for this. Project's page is here: http://cerber.sourceforge.net And rest of policies: http://cerber.sourceforge.net/policies/ CerbNG works only on 4-STABLE systems for now and there will be soon 1.0-RC2 version, but I've started porting it to -CURRENT. -- Pawel Jakub Dawidek [EMAIL PROTECTED] UNIX Systems Programmer/Administrator http://garage.freebsd.pl Am I Evil? Yes, I Am! http://cerber.sourceforge.net pgp0.pgp Description: PGP signature
Re: Bug in make(1)?
On Thu, Apr 03, 2003 at 11:43:39PM -0800, Terry Lambert wrote: +> IMO, it's better to use ".PATH:", which makes the problem go away, +> by making the linker look for the objects where the compiler put +> them (instead of making the compiler put them where the linker is +> looking). See previous message. Indeed, thanks! -- Pawel Jakub Dawidek [EMAIL PROTECTED] UNIX Systems Programmer/Administrator http://garage.freebsd.pl Am I Evil? Yes, I Am! http://cerber.sourceforge.net pgp0.pgp Description: PGP signature
Re: Bug in make(1)?
On Fri, Apr 04, 2003 at 02:03:35AM +0200, Dimitry Andric wrote: +> Therefore, the simplest solution is to specify -o options everywhere. +> I've attached a patch for /usr/share/mk/sys.mk that does this, but +> please beware, it might break stuff which *expects* output files to +> always be put in the current directory. And this is IMHO correct behaviour. I'll try to build world and kernel with this patch and I'm quite sure that this doesn't break anything. Thanks. -- Pawel Jakub Dawidek [EMAIL PROTECTED] UNIX Systems Programmer/Administrator http://garage.freebsd.pl Am I Evil? Yes, I Am! http://cerber.sourceforge.net pgp0.pgp Description: PGP signature
Re: Bug in make(1)?
On Thu, Apr 03, 2003 at 01:50:59PM -0800, Marcel Moolenaar wrote: +> Because you told make(1) to by virtue of including bsd.prog.mk +> +> OBJS is derived from SRCS by replacing the extension. If SRCS +> contains foo/bar.c, OBJS will contain foo/bar.o... Yes, but take a look on compilation process. When file is compilated '-o' isn't specified (gcc -c test/tst.c), but when executable file is produced, gcc looks for tst.o in test directory (gcc -o tst test/tst.o). And IMHO if gcc want to look for objects somewhere it should put them there, so: gcc -o test/tst.o -c test/tst.c. Sometimes it is hard to change. -- Pawel Jakub Dawidek [EMAIL PROTECTED] UNIX Systems Programmer/Administrator http://garage.freebsd.pl Am I Evil? Yes, I Am! http://cerber.sourceforge.net pgp0.pgp Description: PGP signature
Bug in make(1)?
Hello hackers... Could someone please explain such make(1) behaviour: % pwd % /home/nick/src/testdir % find . . ./test ./test/tst.c ./Makefile % cat Makefile PROG= tst SRCS= test/tst.c .include % make Warning: Object directory not changed from original /usr/home/nick/src/testdir cc -O -pipe -c test/tst.c cc -O -pipe -o tst test/tst.o cc: test/tst.o: No such file or directory cc: No input files specified *** Error code 1 Stop in /usr/home/nick/src/testdir. % ls test/tst.o ls: test/tst.o: No such file or directory % ls tst.o tst.o IMHO make(1) should put .o files in current directory _and_ look for them there when producing an executable file. Right? -- Pawel Jakub Dawidek [EMAIL PROTECTED] UNIX Systems Programmer/Administrator http://garage.freebsd.pl Am I Evil? Yes, I Am! http://cerber.sourceforge.net pgp0.pgp Description: PGP signature
Re: CerbNG 1.0-RC1 is now avaliable.
On Fri, Mar 21, 2003 at 01:58:38AM +0100, Pawel Jakub Dawidek wrote: [...] Hackers... We have spend a lot of time on coding cerb, so we count and will be very greatful for _any_ opinions, including "it suck!". -- Pawel Jakub Dawidek UNIX Systems Administrator http://garage.freebsd.pl Am I Evil? Yes, I Am. pgp0.pgp Description: PGP signature
CerbNG 1.0-RC1 is now avaliable.
Good news everyone. After six months of hard work, many hundreds CVS commits and lots of lost nights we would like to proudly announce, that the CerbNG project released first generally available version (1.0-RC1) of it's kernel security module. It is hard to write some terse words of encouragement for using/testing a program which we have worked on for so long. Nevertheless, we will try to do it in this message. CerbNG is a kernel module for FreeBSD version 4.x (5.x version soon to come). Our main purpose is providing the administrator with tools for enforcing fine grained control for critical system applications/processes/environments, i.e. privileged daemons (not only those running with uid 0), and setuid programs. But it is just a small part of CerbNG functionality. Lead principles in CerbNG development are transparency and flexibility. Sysadmins often do not have time and resources to patch all buggy applications, even for security related vulnerabilities. For defining the system protecting rules, we use a flexible language vaguely similar to C. Some basic CerbNG capabilities are: - detailed control and validation of selected system calls and their arguments - ability of changing syscall arguments and returned values - possibility of modifying process properties and environment - modifying sysctls during process runtime depending on process behavior and context - precise and configurable logging - intuitive, flexible and powerful rule description language Tarball for Version 1.0-RC1 contains some example policy files described below: openssh.cb - Controls sshd(8) (if sshd is running when the policy is being loaded, it has to be restarted). The policy degrades sshd privileges after it's been started to uid and gid for user/group sshd. CerbNG elevates sshd rights for performing privileged operations only. passwd.cb - Controls passwd(1). Similarly to openssh.cb, privileges of the passwd process are changed to those of user running this program. Privileges are degraded regardless of the setuid bit on /usr/bin/passwd. ping.cb, su.cb - Similar privilege degradation examples. noexec-by-group.cb - Noexec for all users but root and members of exec group. Additionally environment variables with names beginning with LD_ are checked. degrade-unknown-sugids.cb - All setuid/setgid files, which are not controlled by Cerb are denied elevated privileges and run with credentials of user performing the execve(2) syscall. restricted-debug.cb - Using ptrace(2) and ktrace(2) syscalls will be limited to root user and members of 'debug' group. restricted-link.cb - Non-root users will be denied the right to create hard links to other users' files. log-exec.cb - All execve(2) calls performed by non-privileged users will be logged. We encourage all interested members of FreeBSD community to testing, sharing ideas/comments and last but not least - reporting bugs. We hope, that CerbNG becomes another useful tool for improving security of servers running FreeBSD. CerbNG CVS repository and latest tarballs are available at: http://sourceforge.net/projects/cerber/ For detailed installation instructions see INSTALL file, or HOWTO.html at: http://cerber.sourceforge.net/docs/HOWTO.html Project HomePage: http://cerber.sourceforge.net/ We invite all interested users and would-be users to subscription of our mailing lists. To subscribe those lists, visit: http://lists.sourceforge.net/mailman/listinfo/cerber-list http://lists.sourceforge.net/mailman/listinfo/cerber-commits CerbNG authors are: Pawel Jakub Dawidek <[EMAIL PROTECTED]> Cerb project initiator, head programmer, kernel part developer, polish documentation author. Slawek Zak <[EMAIL PROTECTED]> Designer of CerbNG configuration language syntax and compiler structure, author of userland policy compiler, documentation translator. PS. We are also preparing a technical document for BSDCon 2003. -- Pawel Jakub Dawidek UNIX Systems Administrator http://garage.freebsd.pl Am I Evil? Yes, I Am. pgp0.pgp Description: PGP signature
Re: Jail seperation patch
On Thu, Feb 27, 2003 at 07:16:15AM -0800, Mooneer Salem wrote: +> Actually, I just gave it blah.lifeafterking.org in /etc/hosts. 10.0.0.4 +> really *is* in the same jail: +> +> %ifconfig +> lnc0: flags=8843 mtu 1500 +> inet 10.0.0.3 netmask 0x broadcast 10.0.0.3 +> inet 10.0.0.4 netmask 0x broadcast 10.0.0.4 +> ether 00:50:56:e0:26:54 +> lo0: flags=8049 mtu 16384 +> %hostname +> test.lifeafterking.org +> % Ehh, so now I know nothing about your test settings. After all problems isn't so trivial. +> As for the hide files code, I found a possible location for it, in +> vfs_subr.c (extattr_check_cred()). I added +> this block to it: [...] IMHO very dirty and not complete. Jail don't have to be chrooted to diferent mount-point, and checks like those should be done between vnodes, not pathnames. In my opinion better way is just create another jail and don't give access to main host for regular users. -- Pawel Jakub Dawidek UNIX Systems Administrator http://garage.freebsd.pl Am I Evil? Yes, I Am. pgp0.pgp Description: PGP signature
Re: Jail seperation patch
On Wed, Feb 26, 2003 at 02:48:25PM -0800, Mooneer Salem wrote: +> 1. It handles at least case 1 just fine: +> +> %telnet 10.0.0.2 25 +> Trying 10.0.0.2... +> Connected to pacific.lifeafterking.org. [...] +> %telnet 10.0.0.3 25 +> Trying 10.0.0.3... +> Connected to test.lifeafterking.org.. [...] +> %telnet 10.0.0.4 25 +> Trying 10.0.0.4... +> Connected to blah.lifeafterking.org.. Nope, this is incorrect behaviour. INADDR_ANY in jail means: 10.1.1.2 or 10.1.1.3, but not 10.1.1.4. +> 2. Neat. :) I'm going to add sysctls when I get a chance for the mount +> hiding. Also, I'm going to take a look +> at the VFS code and see if I can hide files from non-root non-jailed users. ??? Everything that you can check IMHO is to check every parent directory of opened file if it isn't equal to jail chroot directory. But this is slow and stupid, because there could be many jails with shared chroot directory. +> 3. Does multi-level jailing add any further restrictions to the jails within +> the jails, besides the standard ones +> imposed? Nope, but jail runned in jail can't use IPs that aren't binded to parent jail and securelevels are checked recursively. -- Pawel Jakub Dawidek UNIX Systems Administrator http://garage.freebsd.pl Am I Evil? Yes, I Am. pgp0.pgp Description: PGP signature
Re: patch: (forw) linux_sigvec.c
On Wed, Feb 26, 2003 at 02:39:34PM +0100, Martin Blapp wrote: +> > Nice work, I'm wondering if something will be ever commited:) +> +> Of course it will be committed ! But many of us are rather +> busy, that explains why you don't get instant feedback sometimes. +> +> And I really really think that you need a mentor to be able to +> be a src committer. I'll ask whoever I can. Hmm, sounds cool:) +> > Better solution is created separated memory zones for main host and every +> > jail, look at my patch agains 5.0-CURRENT: +> > +> >http://garage.freebsd.pl/privipc.tbz=20 +> >http://garage.freebsd.pl/privipc.README +> +> Ehrm. This patch is still against STABLE. Can you make a version +> for 5.X (shouldn't be that hard) which we can review and commit ? When I announced this patch, I've wrote, that I could prepare patches against -CURRENT when somebody review those against -STABLE:) +> Can you change your homepage to reflect which parts are for 4.X and +> 5.X ? Cool homepage btw, many cool patches on it ;) Hmm, I'll think this over. +> I'll test it this evening on a old STABLE box. Thanks! -- Pawel Jakub Dawidek UNIX Systems Administrator http://garage.freebsd.pl Am I Evil? Yes, I Am. pgp0.pgp Description: PGP signature
Re: Jail seperation patch
On Tue, Feb 25, 2003 at 02:47:11PM -0800, Mooneer Salem wrote: +> I've been working on extending the jail feature of FreeBSD to make it +> more friendly to VPS providers. I added the following features: +> +> * Rudimentary CPU/RAM/number of processes per-jail limits +> * Multiple IP support (from Pawel Jakub Dawidek's mijail patch for 4.7) +> * Proper INADDR_ANY support added (so INADDR_ANY will bind to all IP +> addresses +> within a jail) And what when we got situation like: 1. main host ips: 1.1.1.2, 1.1.1.3, 1.1.1.4 jailed host ips: 1.1.1.2, 1.1.1.3 Daemon in jail binds to INADDR_ANY to port X, somebody connects to port X, but to IP 1.1.1.4 (outside jail). Connection will success? 2. main host ips: 1.1.1.2, 1.1.1.3, 1.1.1.4 jailed host ips: 1.1.1.2, 1.1.1.3 Daemon outside jail binds to port X on IP 1.1.1.4. User in jail connects to port X to INADDR_ANY. Connection will success? What when daemon idside jail and daemon outside jail binds to those same port? If I'm connectin to this port who will handle connection? +> * struct prison added to SysV IPC code (to allow for secure use) Better solution is created separated memory zones for main host and every jail, look at my patch agains 5.0-CURRENT: http://garage.freebsd.pl/privipc.tbz http://garage.freebsd.pl/privipc.README +> * Disk mount hiding Better way is IMHO hiding and cutting pathnames, look at: http://garage.freebsd.pl/jailfsstat.tgz http://garage.freebsd.pl/jailfsstat.README +> * Hot add/remove IP addresses from jail using sysctl +> * Process hiding (non-root users outside jails cannot see jailed processes) This isn't a complete solution and I think it couldn't be, because you still could modify files owned by jailed users with UID notjailed user, so... +> The patch is for 5.0-CURRENT/5.0-RELEASE. I would be interested in +> any comments or suggestions. If anyone's interested, it can be retrieved +> at http://msalem.translator.cx/dist/jail_seperation.v5.patch. You could add multi-level jailing, IMHO it's cool: http://garage.freebsd.pl/mljail.tbz http://garage.freebsd.pl/mljail.README Nice work, I'm wondering if something will be ever commited:) -- Pawel Jakub Dawidek UNIX Systems Administrator http://garage.freebsd.pl Am I Evil? Yes, I Am. pgp0.pgp Description: PGP signature
Re: Multi-level jailing.
On Thu, Feb 20, 2003 at 10:05:52AM -0500, Robert Watson wrote:
+> > I have prepared patch for jail functionality against FreeBSD
+> > 5.0-CURRENT. It provides multi-level jailing and multiple ips for
+> > jails.
+>
+> Sounds cool, although I haven't had a chance to read the patch yet.
+> Question: how did you handle the problem (if at all) that INADDR_ANY
+> doesn't perform a wildcard binding with multiple IPs in the same jail?
+> It's not strictly required that it be handled, but it was always one of
+> the semantic problems I bumped into when I experimented with more IPs. A
+> single-IP jail "works" because it maps INADDR_ANY into the only IP
+> available. I'll try to get a box up and running with these changes in the
+> next few days and give them a spin.
Hmm, this problem is still there, but I think that we could resolve it
by changing all code where IP is compared to INADDR_ANY, to function
like this:
int
prison_inaddr_any(struct ucred *cred, u_int32_t ip)
{
register u_int i;
register struct prison *pr = cred->cr_prison;
if (!jailed(cred))
return (ip == INADDR_ANY);
for (i = 0; i < pr->pr_nips; ++i) {
if (pr->pr_ips[i] == ip)
return (1);
}
return (0);
}
And remove mapping to specified IP, INADDR_ANY should stay there.
--
Pawel Jakub Dawidek
UNIX Systems Administrator
http://garage.freebsd.pl
Am I Evil? Yes, I Am.
msg40065/pgp0.pgp
Description: PGP signature
Re: Ok, IPC jailed.
On Wed, Feb 19, 2003 at 07:43:19PM +0100, Pawel Jakub Dawidek wrote:
+> Patches are attached.
Now!:)
--
Pawel Jakub Dawidek
UNIX Systems Administrator
http://garage.freebsd.pl
Am I Evil? Yes, I Am.
diff -ru /sys/compat/linux/linux_ipc.c sys/compat/linux/linux_ipc.c
--- /sys/compat/linux/linux_ipc.c Wed Feb 19 19:29:13 2003
+++ sys/compat/linux/linux_ipc.cWed Feb 19 18:02:21 2003
@@ -25,7 +25,7 @@
* (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF
* THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
*
- * $FreeBSD: src/sys/compat/linux/linux_ipc.c,v 1.17.2.3 2001/11/05 19:08:22 marcel
Exp $
+ * $FreeBSD$
*/
#include
@@ -34,6 +34,7 @@
#include
#include
#include
+#include
#include
#include
@@ -222,6 +223,12 @@
int error;
union semun *unptr;
caddr_t sg;
+ struct sempriv *sp;
+
+ if (p->p_prison == NULL)
+ sp = &mainsem;
+ else
+ sp = &p->p_prison->pr_sem;
sg = stackgap_init();
@@ -278,7 +285,7 @@
sizeof(linux_seminfo) );
if (error)
return error;
- bcopy(&seminfo, &linux_seminfo, sizeof(linux_seminfo) );
+ bcopy(&sp->seminfo, &linux_seminfo, sizeof(linux_seminfo) );
/* XXX BSD equivalent?
#define used_semids 10
#define used_sems 10
@@ -289,7 +296,7 @@
sizeof(linux_seminfo) );
if (error)
return error;
- p->p_retval[0] = seminfo.semmni;
+ p->p_retval[0] = sp->seminfo.semmni;
return 0; /* No need for __semctl call */
case LINUX_GETALL:
/* FALLTHROUGH */
diff -ru /sys/kern/kern_exit.c sys/kern/kern_exit.c
--- /sys/kern/kern_exit.c Wed Feb 19 19:29:13 2003
+++ sys/kern/kern_exit.cWed Feb 19 18:38:38 2003
@@ -36,11 +36,12 @@
* SUCH DAMAGE.
*
* @(#)kern_exit.c 8.7 (Berkeley) 2/12/94
- * $FreeBSD: src/sys/kern/kern_exit.c,v 1.92.2.11 2003/01/13 22:51:16 dillon Exp $
+ * $FreeBSD$
*/
#include "opt_compat.h"
#include "opt_ktrace.h"
+#include "opt_sysvipc.h"
#include
#include
@@ -57,6 +58,7 @@
#include
#include /* for acct_process() function prototype */
#include
+#include
#include
#include
#include
@@ -510,6 +512,15 @@
if (p->p_prison && !--p->p_prison->pr_ref) {
if (p->p_prison->pr_linux != NULL)
FREE(p->p_prison->pr_linux, M_PRISON);
+#ifdef SYSVMSG
+ msgclear(p->p_prison);
+#endif
+#ifdef SYSVSEM
+ semclear(p->p_prison);
+#endif
+#ifdef SYSVSHM
+ shmclear(p->p_prison);
+#endif
FREE(p->p_prison, M_PRISON);
}
diff -ru /sys/kern/kern_jail.c sys/kern/kern_jail.c
--- /sys/kern/kern_jail.c Wed Feb 19 19:29:13 2003
+++ sys/kern/kern_jail.cWed Feb 19 19:29:09 2003
@@ -6,10 +6,12 @@
* this stuff is worth it, you can buy me a beer in return. Poul-Henning Kamp
*
*
- * $FreeBSD: src/sys/kern/kern_jail.c,v 1.6.2.3 2001/08/17 01:00:26 rwatson Exp $
+ * $FreeBSD$
*
*/
+#include "opt_sysvipc.h"
+
#include
#include
#include
@@ -21,6 +23,9 @@
#include
#include
#include
+#include
+#include
+#include
#include
#include
@@ -39,10 +44,12 @@
&jail_socket_unixiproute_only, 0,
"Processes in jail are limited to creating UNIX/IPv4/route sockets only");
-intjail_sysvipc_allowed = 0;
+#if defined(SYSVMSG) || defined(SYSVSEM) || defined(SYSVSHM)
+intjail_sysvipc_allowed = 1;
SYSCTL_INT(_jail, OID_AUTO, sysvipc_allowed, CTLFLAG_RW,
&jail_sysvipc_allowed, 0,
"Processes in jail can use System V IPC primitives");
+#endif
int
jail(p, uap)
@@ -75,7 +82,32 @@
error = chroot(p, &ca);
if (error)
goto bail;
-
+#ifdef SYSVMSG
+ error = msginit(pr);
+ if (error != 0)
+ goto bail;
+#endif
+#ifdef SYSVSEM
+ error = seminit(pr);
+ if (error != 0) {
+#ifdef SYSVMSG
+ msgclear(pr);
+#endif
+ goto bail;
+ }
+#endif
+#ifdef SYSVSHM
+ error = shminit(pr);
+ if (error != 0) {
+#ifdef SYSVMSG
+ msgclear(pr);
+#endif
+#ifdef SYSVSEM
+ semclear(pr);
+#endif
+ goto bail;
+ }
+#endif
pr->pr_ref++;
p->p_prison = pr;
p->p_flag |= P_JAILED;
diff -ru /sys/kern/sysv_msg.c sys/kern/sysv_msg.c
--- /sys/kern/sysv_msg.c
Ok, IPC jailed.
Hello hackers... I prepared patches against 4.7-STABLE for secure IPC in jail. Main host and every jail has separated IPC memory zones, etc. I have added some sysctls and set-gid on group kmem for ipcs(1) is nomore needed. I could port those patches against 5.x if someone will review and commit it maybe. So, any volunteers?:) Patches are attached. -- Pawel Jakub Dawidek UNIX Systems Administrator http://garage.freebsd.pl Am I Evil? Yes, I Am. msg40036/pgp0.pgp Description: PGP signature
IPC and jail.
Hello hackers. I'm preparing a patch against FreeBSD 4.7 (for now) which splits IPC zones between jails and main host. Every entity will have his own IPC memory not shared with others (jails or main host). Message queues are already patched, but it need to be tested - that's why I'm writing. Does anybody have any regression tests for IPC functionality? If not, which program use it and will be a good test? Thanks. -- Pawel Jakub Dawidek UNIX Systems Administrator http://garage.freebsd.pl Am I Evil? Yes, I Am. msg39981/pgp0.pgp Description: PGP signature
Re: Multi-level jailing.
Now patch is attached:)
--
Pawel Jakub Dawidek
UNIX Systems Administrator
http://garage.freebsd.pl
Am I Evil? Yes, I Am.
diff -ru /usr/src/sys/kern/kern_jail.c ./sys/kern/kern_jail.c
--- /usr/src/sys/kern/kern_jail.c Tue Jan 21 09:55:54 2003
+++ ./sys/kern/kern_jail.c Mon Feb 17 07:11:42 2003
@@ -6,7 +6,7 @@
* this stuff is worth it, you can buy me a beer in return. Poul-Henning Kamp
*
*
- * $FreeBSD: src/sys/kern/kern_jail.c,v 1.29 2003/01/21 08:55:54 alfred Exp $
+ * $FreeBSD$
*
*/
@@ -28,6 +28,14 @@
MALLOC_DEFINE(M_PRISON, "prison", "Prison structures");
+#ifndef OLDJAIL
+SLIST_HEAD(, prison_children) prison_head =
+SLIST_HEAD_INITIALIZER(&prison_head);
+struct mtx prison_head_mtx;
+MTX_SYSINIT(prison_head_lock, &prison_head_mtx, "prison_head mutex lock",
+MTX_DEF);
+#endif
+
SYSCTL_DECL(_security);
SYSCTL_NODE(_security, OID_AUTO, jail, CTLFLAG_RW, 0,
"Jail rules");
@@ -65,11 +73,18 @@
struct jail j;
struct chroot_args ca;
struct ucred *newcred = NULL, *oldcred;
+#ifndef OLDJAIL
+ u_int i;
+#endif
error = copyin(uap->jail, &j, sizeof j);
if (error)
return (error);
+#ifdef OLDJAIL
if (j.version != 0)
+#else
+ if (j.version != 1)
+#endif
return (EINVAL);
MALLOC(pr, struct prison *, sizeof *pr , M_PRISON, M_ZERO);
@@ -85,12 +100,40 @@
if (error)
goto bail;
newcred = crget();
+#ifdef OLDJAIL
pr->pr_ip = j.ip_number;
+#else
+ MALLOC(pr->pr_ips, u_int32_t *, sizeof(u_int32_t) * j.nips, M_PRISON,
+ 0);
+ error = copyin(j.ips, pr->pr_ips, sizeof(u_int32_t) * j.nips);
+ if (error) {
+ FREE(pr->pr_ips, M_PRISON);
+ goto bail;
+ }
+ if (jailed(p->p_ucred)) {
+ for (i = 0; i < j.nips; ++i) {
+ if (!prison_validip(p->p_ucred, pr->pr_ips[i])) {
+ error = EINVAL;
+ FREE(pr->pr_ips, M_PRISON);
+ goto bail;
+ }
+ }
+ }
+ pr->pr_nips = j.nips;
+#endif
+
+#ifdef OLDJAIL
PROC_LOCK(p);
/* Implicitly fail if already in jail. */
error = suser_cred(p->p_ucred, 0);
if (error)
goto badcred;
+#else
+ pr->pr_pprison = p->p_ucred->cr_prison;
+ SLIST_INIT(&pr->pr_children);
+ prison_addchild(p->p_ucred->cr_prison, pr);
+ PROC_LOCK(p);
+#endif
oldcred = p->p_ucred;
crcopy(newcred, oldcred);
p->p_ucred = newcred;
@@ -99,7 +142,9 @@
PROC_UNLOCK(p);
crfree(oldcred);
return (0);
+#ifdef OLDJAIL
badcred:
+#endif
PROC_UNLOCK(p);
crfree(newcred);
bail:
@@ -111,14 +156,56 @@
void
prison_free(struct prison *pr)
{
+#ifndef OLDJAIL
+ struct prison_children *pc;
+ struct prison *ppr;
+#endif
mtx_lock(&pr->pr_mtx);
pr->pr_ref--;
if (pr->pr_ref == 0) {
+#ifndef OLDJAIL
+ ppr = pr->pr_pprison;
+ pc = NULL;
+ if (ppr == NULL) {
+ mtx_lock(&prison_head_mtx);
+ SLIST_FOREACH(pc, &prison_head, pc_next) {
+ if (pc->pc_child == pr)
+ break;
+ }
+ SLIST_REMOVE(&prison_head, pc, prison_children,
+ pc_next);
+ } else {
+ SLIST_FOREACH(pc, &ppr->pr_children, pc_next) {
+ if (pc->pc_child == pr)
+ break;
+ }
+ SLIST_REMOVE(&ppr->pr_children, pc, prison_children,
+ pc_next);
+ }
+ KASSERT(pc != NULL, ("Child have to be on list."));
+ FREE(pc, M_PRISON);
+ SLIST_FOREACH(pc, &pr->pr_children, pc_next) {
+ mtx_lock(&pc->pc_child->pr_mtx);
+ pc->pc_child->pr_pprison = ppr;
+ mtx_unlock(&pc->pc_child->pr_mtx);
+ if (ppr == NULL)
+ SLIST_INSERT_HEAD(&prison_head, pc, pc_next);
+ else {
+ SLIST_INSERT_HEAD(&ppr->pr_children, pc,
+ pc_next);
+ }
+ }
+ if (ppr == NULL)
+ mtx_unlock(&prison_head_mtx);
+#endif /* !OLDJAIL */
mtx_unloc
Multi-level jailing.
Hello hackers. I have prepared patch for jail functionality against FreeBSD 5.0-CURRENT. It provides multi-level jailing and multiple ips for jails. Example of use: IPS on machine: tl0: 12.34.56.1 12.34.56.2 12.34.56.3 10.10.10.1 fxp0: 98.76.54.32 98.76.54.31 You can create jails inside of jails: # jail / jail-1 12.34.56.1,12.34.56.2,10.10.10.1,98.76.54.31 /bin/sh [ we are in jail-1 ] # jail / jail-2 12.34.56.1,10.10.10.1,98.76.54.31 /bin/sh [ we are in jail-2 ] # jail / jail-3 12.34.56.1,98.76.54.31 /bin/sh [ we are in jail-3 ] # jail / jail-4 12.34.56.1,10.10.10.1 /bin/sh [ EINVAL, because we are already jailed and want to take IP from outside the jail ] Only processes from jail-2, jail-3 and jail-4 and jail-1 are visable in jail-1. Only processes from jail-4 and jail-3 are visable in jail-3. Jail-2 is child of jail-1, jail-1 is parent of jail-2, jail-3 is child of jail-2, jail-2 is parent of jail-3. If Parent exits, parent of parent will be new parent - If last process of jail-2 exits jail-1 became parent of jail-3 and jail-3 became child of jail-1. Ifconfigs from jails: jail-1# ifconfig rl0: flags=8943 mtu 1500 inet 12.34.56.1 netmask 0xff00 broadcast 12.34.56.255 inet 12.34.56.2 netmask 0x broadcast 12.34.56.2 inet 10.10.10.1 netmask 0x broadcast 10.10.255.255 ether 00:11:22:33:44:55 media: Ethernet autoselect (100baseTX ) status: active rl1: flags=8843 mtu 1500 inet 98.76.54.31 netmask 0x broadcast 98.76.54.31 ether ff:ee:dd:cc:bb:aa media: Ethernet autoselect (100baseTX ) status: active lo0: flags=8049 mtu 16384 jail-2# ifconfig rl0: flags=8943 mtu 1500 inet 12.34.56.1 netmask 0xff00 broadcast 12.34.56.255 inet 10.10.10.1 netmask 0x broadcast 10.10.255.255 ether 00:11:22:33:44:55 media: Ethernet autoselect (100baseTX ) status: active rl1: flags=8843 mtu 1500 inet 98.76.54.31 netmask 0x broadcast 98.76.54.31 ether ff:ee:dd:cc:bb:aa media: Ethernet autoselect (100baseTX ) status: active lo0: flags=8049 mtu 16384 jail-3# ifconfig rl0: flags=8943 mtu 1500 inet 12.34.56.1 netmask 0xff00 broadcast 12.34.56.255 ether 00:11:22:33:44:55 media: Ethernet autoselect (100baseTX ) status: active rl1: flags=8843 mtu 1500 inet 98.76.54.31 netmask 0x broadcast 98.76.54.31 ether ff:ee:dd:cc:bb:aa media: Ethernet autoselect (100baseTX ) status: active lo0: flags=8049 mtu 16384 Patch is attached and also avaliable with README file here: http://garage.freebsd.pl/mljail.tbz -- Pawel Jakub Dawidek UNIX Systems Administrator http://garage.freebsd.pl Am I Evil? Yes, I Am. msg39976/pgp0.pgp Description: PGP signature
Re: Some "security" questions.
On Tue, Feb 11, 2003 at 04:43:46PM -0800, Julian Elischer wrote: +> > Did we somehow break acct(2), or is that somehow inadequate to the task? It +> > should be ideal for what Julian's customer wants, I would think. See also +> > acct(5), sa(8) and accton(8). +> +> Acct doesn't give the arguments of the commands +> +> rexec (as pointed out earlier in this thread) does exactly what I want. [...] For logging only, I recommend light-wegiht rexec - lrexec. It can be found at: http://garage.freebsd.pl/lrexec.tbz (actual CVS snapshot) http://garage.freebsd.pl/lrexec.README or at: http://cerber.sourceforge.net/projects/cerber to. And it's better documented atm. -- Pawel Jakub Dawidek UNIX Systems Administrator http://garage.freebsd.pl Am I Evil? Yes, I Am. msg39922/pgp0.pgp Description: PGP signature
Re: Some "security" questions.
On Tue, Feb 11, 2003 at 03:40:28AM +0100, Pawel Jakub Dawidek wrote:
+> +> Anyoone have any modules to REALLY log execs?
+>
+> Yes, we got:
+>
+> http://cerber.sourceforge.net
+>
+> If You want only execve() logging You can try rexec.
Or wait on cerb-ng first release. There is defined such policy
and it looks like:
if (syscall == SYS_execve) {
log(LOG_INFO, "CerbNG:%s(%s): Running %s(%s) (args: %S) "
"[pid=%u, ruid=%u, euid=%u, groups=%U].",
pname, pfname, arg[0], realpath(arg[0]), arg[1],
pid, ruid, euid, groups);
}
Output in logs is something like:
CerbNG:passwd(/usr/bin/passwd): Running pwd_mkdb(/usr/sbin/pwd_mkdb) (args: [
"pwd_mkdb", "-p", "-d", "/etc", "-u", "jules" ]) [pid=666, ruid=1000, euid=0, groups=[
1000, 1000, 0 ]].
--
Pawel Jakub Dawidek
UNIX Systems Administrator
http://garage.freebsd.pl
Am I Evil? Yes, I Am.
msg39875/pgp0.pgp
Description: PGP signature
Re: Some "security" questions.
On Mon, Feb 10, 2003 at 06:03:07PM -0800, Julian Elischer wrote: +> Anyoone have any modules to REALLY log execs? Yes, we got: http://cerber.sourceforge.net If You want only execve() logging You can try rexec. -- Pawel Jakub Dawidek UNIX Systems Administrator http://garage.freebsd.pl Am I Evil? Yes, I Am. msg39872/pgp0.pgp Description: PGP signature
Re: Missing commit bit [PATCH].
On Wed, Feb 05, 2003 at 05:10:33PM +0200, Giorgos Keramidas wrote: +> Please don't submit bogus PRs like this. It's actually funny, but the +> people who receive the messages from new PR submissions ar already +> flooded with many things. Let us not increase their load by creating +> many PRs that they have to close. +> +> Cross-posting to -hackers is also a bit Evil(TM) since anyone who hits +> reply to the original post and forgets to remove freeBSD-gnats-submit +> from the list of recipients will generate a misfiled PR, which I will +> have to search for and close later. There are already quite a few +> misfiled PRs that we have to handle periodically. We don't need more. +> +> Please... don't abuse gnats for things that are not bug reports. Yes, I know. Sorry for that, but this wasn't exactly "funny". I have seen post on /. and I understand that, I also respect decisions of core team and trust them, right? It is just so fuckin strange and hard to understand and (uhm) live with it. From my perspective. Commit access is directly connected with FreeBSD. So we can throw away any personal reasons, am I right? If so, tell me now, please, what kind of reasons left, that can't be shown in public forum? Ok, I stop here, but IMHO we're loosing "opensource" nature... PS. This isn't my curiosity and I'm not gay, but I just want Matt back. -- Pawel Jakub Dawidek UNIX Systems Administrator http://garage.freebsd.pl Am I Evil? Yes, I Am. msg39652/pgp0.pgp Description: PGP signature
Re: Missing commit bit [PATCH].
On Tue, Feb 04, 2003 at 10:48:40AM +0100, Pawel Jakub Dawidek wrote: +> There is commit bit for Matthew Dillon <[EMAIL PROTECTED]>. Grr:) s/is/ISN'T/ -- Pawel Jakub Dawidek UNIX Systems Administrator http://garage.freebsd.pl Am I Evil? Yes, I Am. msg39615/pgp0.pgp Description: PGP signature
Missing commit bit [PATCH].
>Submitter-Id: current-users >Originator: Pawel Jakub Dawidek >Organization: >Confidential: no >Synopsis: Missing commit bit [PATCH]. >Severity: critical >Priority: high >Category: misc >Class: change-request >Release: All of them. >Environment: Any. >Description: There is commit bit for Matthew Dillon <[EMAIL PROTECTED]>. It was removed without any explanation. >How-To-Repeat: Don't repeat it. Ever. >Fix: Here is appropriate patch: --- access.orig Tue Feb 4 10:44:28 2003 +++ access Tue Feb 4 10:44:59 2003 @@ -1,5 +1,5 @@ # -# $FreeBSD: CVSROOT/access,v 1.364 2003/02/02 09:01:30 markm Exp $ +# $FreeBSD$ # # Please try to keep the handbook (contrib/chapter.sgml authors.ent # staff/chapter.sgml) in in sync with this. @@ -164,6 +164,7 @@ andy imura jmas +dillon bp wsanchez dan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Routing within a Jail
On Sun, Feb 02, 2003 at 09:10:58PM +0600, Yakov Sudeikin wrote: +> [...] As far as I know this is +> not possible, jail is started binded to single IP. [...] You can try my patch for multiple ips in jail: http://garage.freebsd.pl/mijail.README http://garage.freebsd.pl/mijail.tbz -- Pawel Jakub Dawidek UNIX Systems Administrator http://garage.freebsd.pl Am I Evil? Yes, I Am. msg39559/pgp0.pgp Description: PGP signature
Re: Exceptions via setjmp/longjmp in kernel.
On Thu, Jan 09, 2003 at 10:51:13AM -0800, Julian Elischer wrote: +> how do you ensure that the thread doesn't own any locks when it does the +> longjmp? Hmm, hard to explain. I got my own infrastructure for this and every locks that are done I got in my-threads, so I just have to check those thread when setjmp() returns value != 0 and release them. I got also my own functions for locking/unlocking data based on tsleep()/wakeup_one() functions. For now this works only on 4.x, but I want to be prepare for 5.x (but I don't understand mutexes handling for now). Also... I got setjmp() only in one place and when I'm returning with longjmp() I need to just unlock everything that was locked between setjmp() and longjmp() and this is easy, because every lock is stored in my-thread structure. -- Pawel Jakub Dawidek UNIX Systems Administrator http://garage.freebsd.pl Am I Evil? Yes, I Am. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Exceptions via setjmp/longjmp in kernel.
On Thu, Jan 09, 2003 at 11:03:55AM -0500, Jake Burkholder wrote: +> The kernel longjmp only ever seems to return 1. See i386/i386/support.s. That's right, thanks! But this is strange, setjmp/longjmp are defined in C99 and there setjmp() returns value from longjmp(). -- Pawel Jakub Dawidek UNIX Systems Administrator http://garage.freebsd.pl Am I Evil? Yes, I Am. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Exceptions via setjmp/longjmp in kernel.
Hello hackers...
I got strange problem when trying to implement something like exceptions
with setjmp()/longjmp() functions.
[...]
int ret;
jmpbuf buf;
[...]
ret = setjmp(buf);
KASSERT(ret != 1, ("I never return 1 with longjmp()."));
[...]
longjmp(buf, value_diffrent_than_1);
[...]
And setjmp() returns only 0 or 1 (when longjmp() is called), but never
returns value that I've put in longjmp() call.
There could be some other problems in using setjmp()/longjmp()
in kernel? I'm paying attention on memory leaks and locks that are
done before longjmp().
--
Pawel Jakub Dawidek
UNIX Systems Administrator
http://garage.freebsd.pl
Am I Evil? Yes, I Am.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: Caching [sugestion].
On Mon, Jan 06, 2003 at 07:32:23PM -0800, Terry Lambert wrote:
+> > Example rules:
+> >
+> > We want to permit those operations:
+> > - opening file /etc/master.passwd for read only,
+> > - opening files that match to /tmp/temp.* for write,
+> > - changing mode of files /tmp/temp.* to '0666', BUT via fchmod(2).
+>
+> Here is an example:
+>
+> ln /etc/passwd /tmp/temp.hack_Pawels_passwd_file_by_abusing_a_bad_rule
+>
+> fd = open( "/tmp/...", O_RDWR, 0);
+>
+> ...Oh look, I've just abused permissions that come from MAC based
+> on inheritance, with a hard link, in order to hack the password file...
Not exactly. In my project You got special, very flexible language,
so You can create more compilicated rules for situation like this:
if (syscall == SYS_open && pname == "our_process" && [ more tests ]) {
reg[0] = realpath(arg[0]);
if (reg[0] @ "/tmp/temp.*" && arg[1] == (O_RDWR | O_CREAT)) {
/* This is important. */
if (getnlinks(arg[0]) == 1) {
/* Permit this operation. */
return(call());
}
}
}
if (syscall == SYS_fchmod) {
/* let's take file name of descriptor */
reg[0] = fd2name(arg[0]);
if (reg[0] @ "/tmp/temp.*" && arg[1] == 0666) {
/* We can check number of hardlinks one more time. */
if (fd2nlinks(arg[0]) == 1) {
/* Permit this operation. */
return(call());
}
}
}
[ arg[X] are table with syscall arguments,
reg[X] are registers that could store values ]
So our process can only open and fchmod file that match to /tmp/temp.*
when it have no hardlinks at all.
I can even create rules that will prohibit creating hard links to file
not owned be user who is calling link(2):
if (syscall == SYS_link && ruid > 0) {
if (getouid(arg[0]) != ruid) {
return(EPERM);
}
}
Other think that I could remember dev_t/ino_t pair, because registers
that are use in examples aren't cleaned, so:
if (syscall == SYS_open && pname == "our_process" && [ more tests ]) {
reg[0] = realpath(arg[0]);
if (reg[0] @ "/tmp/temp.*" && arg[1] == (O_RDWR | O_CREAT)) {
/* This is important. */
if (getnlinks(arg[0]) == 1) {
/* Remember ino_t/dev_t pair. */
reg[10] = getinode(arg[0]);
reg[11] = getdev(arg[0]);
/* Permit this operation. */
return(call());
}
}
}
if (syscall == SYS_fchmod) {
/* let's take file name of descriptor */
reg[0] = fd2name(arg[0]);
if (reg[0] @ "/tmp/temp.*" && arg[1] == 0666) {
/* We can check number of hardlinks one more time. */
if (fd2nlinks(arg[0]) == 1) {
/* Check remembered ino_t/dev_t. */
if (fd2inode(arg[0] == reg[10] &&
fd2dev(arg[0] == reg[11])) {
/* Permit this operation. */
return(call());
}
}
}
}
Storing ino_t/dev_t pair was added to be sure that someone don't unlink()
or rename() our file and create new one with same name.
+> The "simple, clean way" is to disallow hard links, and cache the
+> parent directory inode on every VOP_CREATE and VOP_MKDIR operation.
+>
+> The "less simple, but clean way" to do it is to create a file system
+> object called a "link node", for use by hard links, and to seperate
+> the vmobject_t reference out of the vnode, so that each path gets a
+> seperate vnode, and each vnode that's actually an object alias gets
+> the same vmobject_t reference, instead of having its own.
But please, understand me. I don't want to patch kernel at all.
This have to be done from kld module.
PS. I think this over againg and You and Julian Elischer probably have
right - I need to update cached names on rename(2) and unlink(2).
--
Pawel Jakub Dawidek
UNIX Systems Administrator
http://garage.freebsd.pl
Am I Evil? Yes, I Am.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: Caching [sugestion].
On Mon, Jan 06, 2003 at 04:58:16PM -0800, Julian Elischer wrote: +> >We want to permit those operations: +> >- opening file /etc/master.passwd for read only, +> >- opening files that match to /tmp/temp.* for write, +> >- changing mode of files /tmp/temp.* to '0666', BUT via fchmod(2). +> > +> >How to do that correct? +> >There is no chance to do this in simple, clean way. +> +> you would have to attach a 'chmod capability' to the file descriptor +> when you open it.. in other words it would be pre-decided at open time. +> +> Even if you remembered what name was used when you openned it you would +> have no proof that it still had that name when you do the chmod. Right! But that's ok. Look at rules - I just nedd to know file name when file was opened. I was thinking to add to my ugly way catching rename(2) and changing cached file name, but this is really unnecessary. It's even better that file name isn't updated on rename(2). -- Pawel Jakub Dawidek UNIX Systems Administrator http://garage.freebsd.pl Am I Evil? Yes, I Am. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Caching [sugestion].
On Mon, Jan 06, 2003 at 03:53:38PM -0800, Terry Lambert wrote: +> If this were my job to do, I would either take the approach of +> changing how hard links and vmobject_t references are implemented, +> or I would disallow hard links, and add a "parent inode" field in +> one of the spare fields in each inode. +> +> If you did either one of these, then you chould always ask the open +> file for the vnode, and add a VOP that took the vnode, got the inode, +> amd then traversed to the root, looking in the parent for the inode +> of the object itself. Yes, but I need this functionality from kld module and there are no tools for that in kernel atm. +> > So I'm not able to create policy rules based on filenames. +> +> That's precisely correct: you are unable to create policy rules +> based on file names, because file names are references to files, +> and are not themselves file insteances. This is not FAT32, where +> there is a 1:1 identity relationship between a directory entry and +> an inode. And that's the origin of your problem. Yes, I know that (sugestion of getting file names (not directory names only) from vnode was mistake). That's why I think that there should be some caching mechanism that should remember file name of every opened file, name of executable and working directory. Example rules: We want to permit those operations: - opening file /etc/master.passwd for read only, - opening files that match to /tmp/temp.* for write, - changing mode of files /tmp/temp.* to '0666', BUT via fchmod(2). How to do that correct? There is no chance to do this in simple, clean way. I've returned to my old, ugly way - caching filenames on open(2) - it's working fine, but is complicated, because I need to catch calls of p->p_fd->fd_ofiles[X]->f_ops->fo_close() functions. -- Pawel Jakub Dawidek UNIX Systems Administrator http://garage.freebsd.pl Am I Evil? Yes, I Am. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Caching [sugestion].
On Mon, Jan 06, 2003 at 08:37:23AM -0800, David Schultz wrote: +> You still haven't explained exactly what you're trying to do, but +> you may wish to look into Niels Provos' Systrace. It should give +> you a good example of how to do system call interposition in the +> kernel, and it has been ported to all three BSDs. +> +> http://www.citi.umich.edu/u/provos/systrace/ +> +> It sounds like you're trying to do something complicated with +> chdir, and that could make things harder. First of all, you +> should be comparing vnodes instead of pathnames when possible, in +> order to avoid canonicalization bugs. Second, it only makes sense +> to ask for the path of a directory vnode, since ordinary files can +> have multiple hard links. For directories, you can get the full +> path by walking up the '..' pointers, sort of like vn_fullpath(), +> except that you have to do a lookup if something is missing from +> the cache. I expect locking would be a pain as well. Yes, I know that already. Soon I'll send announce of what I'm doing, for now I'll use my ugly way. Not always is chance to operate only on vnodes. When You (for example) want to denied mode changes for some file, You can do this through catching chmod(2), but when someone open this file how You get file name when You want create policy rules for fchmod(2)? Remember that files could have temporary names, so You can't compare vnode from file descriptor with some file that You're expecting. PS. No comments about systrace... ever. -- Pawel Jakub Dawidek UNIX Systems Administrator http://garage.freebsd.pl Am I Evil? Yes, I Am. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Caching [sugestion].
On Sun, Jan 05, 2003 at 03:02:18PM -0800, Terry Lambert wrote:
+> This is a much larger problem than you make it out to be.
Yes, right, using vnodes is bad idea, sorry.
I'll describe my problem precisely.
I'm writing kld module where it have to be done.
I got two choices:
- getting path from cache, but this don't give me 100% sure
that I'll get this path (even if it exists),
- (ugly to) catch syscalls:
+ open(),
+ chdir(),
+ fchdir(),
+ execve(),
add two my functions to at_exit() and at_fork() and
(this is ugly as fuck) remember and switch functions
that are called on descriptor close
(p->p_fd->fd_ofiles[X]->f_ops->fo_close()).
With second strategy I could cache filenames:
- name of executable per process (on execve()),
- name of opened file per file descryptor (p->p_fd->p_ofiles[X],
on open()),
- and only name of working directory per vnode (there can't be
hardlinks to directory, so...; on [f]chdir()).
Struct for this could looks like:
struct mycache {
union {
struct file *mc_fp;
struct proc *mc_proc;
struct vnode*mc_vp;
} myunion;
u_int mc_ref;
u_char mc_type;
#define MYTYPE_FILE 0
#define MYTYPE_PROC 1
#define MYTYPE_VNODE2
};
#define mc_fp myunion.mc_fp
#define mc_proc myunion.mc_proc
#define mc_vp myunion.mc_vp
Reference counts are updated on every open/fo_close (for MYTYPE_FILE),
execve/exit/fork (for MYTYPE_PROC) and fork/chdir/fchdir (for MYTYPE_VNODE).
But as You can see, now, if I want to get functionaly what I want,
I need to be _very_ nasty (and evil of course):)
This could be useful in a future, for example in MAC functionality.
Now we got:
static int
mac_none_check_vnode_stat(struct ucred *active_cred, struct ucred *file_cred,
struct vnode *vp, struct label *label)
{
[...]
}
or:
static int
mac_none_check_vnode_write(struct ucred *active_cred,
struct ucred *file_cred, struct vnode *vp, struct label *label)
{
[...]
}
or even:
static int
mac_none_setlabel_vnode_extattr(struct ucred *cred, struct vnode *vp,
struct label *vlabel, struct label *intlabel)
{
[...]
}
So I'm not able to create policy rules based on filenames.
--
Pawel Jakub Dawidek
UNIX Systems Administrator
http://garage.freebsd.pl
Am I Evil? Yes, I Am.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Caching [sugestion].
Hello hackers... I just wondering... Now we got problems with caching, and problems could be seriuos in -CURRENT when we want to use some TrustedBSD features, etc. Sometimes there is NEED to get filename (or full path) from vnode to log selected behaviour or many other useful things (for example property working __getcwd()). For now we could get pathname from cache, but not always it is possible. My sugestion is to add some flags that will describe priority of cached objects. Objects with some flag should be removed from cache only when it's really necessary. This flag should be set for: - working directory of every process (p->p_fd->fd_cdir), - filename of executable (p->p_textvp), - filenames of all opened files )p->p_fd->fd_ofiles[X]->f_data). - maybe something else? On every [f]chdir(), our flag should be removed from actual object and set on new one. Exactly that same for execve() and exit1() and for open() and p->p_fd->fd_ofiles[X]->f_ops->fo_close(). This don't have to be done via VFS caching mechanism, this could also be made by some separated mechanism used only for this. Think over this, please! -- Pawel Jakub Dawidek UNIX Systems Administrator http://garage.freebsd.pl Am I Evil? Yes, I Am. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
