From owner-freebsd-arch Tue Oct 19 1:55:50 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id CB5CC16323 for ; Tue, 19 Oct 1999 01:55:45 -0700 (PDT) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id KAA04298 for ; Tue, 19 Oct 1999 10:55:45 +0200 (CEST) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id KAA82661 for freebsd-arch@freebsd.org; Tue, 19 Oct 1999 10:55:44 +0200 (MET DST) Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id AD51A16323 for ; Tue, 19 Oct 1999 01:55:34 -0700 (PDT) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id KAA04290; Tue, 19 Oct 1999 10:55:27 +0200 (CEST) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id KAA82640; Tue, 19 Oct 1999 10:55:25 +0200 (MET DST) Date: Tue, 19 Oct 1999 10:55:25 +0200 From: Eivind Eklund To: freebsd-arch@freebsd.org Subject: Re: kern.securelevel and X Message-ID: <19991019105525.A82390@bitbox.follo.net> References: <14343.23571.679909.243732@blm30.IRO.UMontreal.CA> <19991017012750.A812@fever.semiotek.com> <380A1E2C.CCA326F5@gorean.org> <19991018024704.A512@semiotek.com> <19991018043039.B1711@semiotek.com> <19991018142633.D1DDB1DA3@bone.nectar.com> <99Oct19.142341est.40352@border.alcanet.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre3i In-Reply-To: <99Oct19.142341est.40352@border.alcanet.com.au> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, Oct 19, 1999 at 02:27:48PM +1000, Peter Jeremy wrote: [On using sysctl's for securelevel-style capabilities that can be dropped] > The disadvantage of this approach is kernel bloat: Each sysctl adds > around 50 bytes of data overhead on an i386 (and about twice this on > an Alpha). A single bitmap (which could still be a sysctl) of allowed > syscalls would be substantially smaller and allow most of the permission > checking inside trap.c:syscall(). First of all, I do not believe that the syscalls provide an adequate mapping to which things you want to protect against. I think you need different knobs if this is to be at all useful. Hardly any of the present securelevel restrictions map to syscalls. Second, looking at the syscall list, I find the following syscalls you might want to block (and which are not already handled by securelevel (with better semantics)): 14 STD POSIX { int mknod(char *path, int mode, int dev); } 21 STD BSD { int mount(char *type, char *path, int flags, \ caddr_t data); } 22 STD BSD { int unmount(char *path, int flags); } 23 STD POSIX { int setuid(uid_t uid); } 26 STD BSD { int ptrace(int req, pid_t pid, caddr_t addr, \ int data); } 36 STD BSD { int sync(void); } 44 STD BSD { int profil(caddr_t samples, size_t size, \ size_t offset, u_int scale); } 45 STD BSD { int ktrace(const char *fname, int ops, int facs, \ int pid); } 55 STD BSD { int reboot(int opt); } 56 STD POSIX { int revoke(char *path); } 61 STD BSD { int chroot(char *path); } 63 COMPAT BSD { int getkerninfo(int op, char *where, size_t *size, \ int arg); } getkerninfo getkerninfo_args int 85 STD BSD { int swapon(char *name); } 88 COMPAT BSD { int sethostname(char *hostname, u_int len); } \ sethostname sethostname_args int 96 STD BSD { int setpriority(int which, int who, int prio); } 134 STD BSD { int shutdown(int s, int how); } 143 COMPAT BSD { int sethostid(long hostid); } 148 STD BSD { int quotactl(char *path, int cmd, int uid, \ caddr_t arg); } 163 STD BSD { int setdomainname(char *domainname, int len); } 166 STD BSD { int rtprio(int function, pid_t pid, \ struct rtprio *rtp); } 203 STD BSD { int mlock(const void *addr, size_t len); } 327 STD POSIX { int sched_setparam (pid_t pid, \ const struct sched_param *param); } 335 STD BSD { int utrace(const void *addr, size_t len); } 338 STD BSD { int jail(struct jail *jail); } We're talking of 23 syscalls that I can see as being relevant for a block. At 50 bytes each, this is 1150 bytes. Of course, for a sysctl based implementation, you would use a different granularity (better fit to reaching particular goals), so it would be less. I don't think this is worth the extra syscall overhead, particularly as the syscalls you would want to block are not on the critical path, while the overhead would be (including cache memory loss). If the kernel bloat is seen as a problem, we could hide it behind a kernel option (though I'm not particularly happy about adding more kernel options). Eivind. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message