Date: Tue, 19 Oct 1999 10:55:25 +0200 From: Eivind Eklund <eivind@freebsd.org> To: freebsd-arch@freebsd.org Subject: Re: kern.securelevel and X Message-ID: <19991019105525.A82390@bitbox.follo.net> In-Reply-To: <99Oct19.142341est.40352@border.alcanet.com.au> References: <14343.23571.679909.243732@blm30.IRO.UMontreal.CA> <19991017012750.A812@fever.semiotek.com> <380A1E2C.CCA326F5@gorean.org> <19991018024704.A512@semiotek.com> <xzpyad12jd7.fsf@flood.ping.uio.no> <19991018043039.B1711@semiotek.com> <xzpso392gj0.fsf@flood.ping.uio.no> <19991018142633.D1DDB1DA3@bone.nectar.com> <xzp90503esj.fsf@flood.ping.uio.no> <99Oct19.142341est.40352@border.alcanet.com.au>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19991019105525.A82390>