Re: regression error with calendar
On 2011-07-05, Julian H. Stacey wrote: Jaakko Heinonen wrote: On 2011-07-05, Julian H. Stacey wrote: There's a regression error with calendar between FreeBSD-8.1 8.2-RELEASES Test data: - Tue+1 TESTX 1 Tuesday+1 TESTX 2 * Tuesday+1 TESTX 3 Tuesday+1 * TESTX 4 Tuesday TESTX5 Tuesday TESTX6 - This look like PR bin/155873 (http://www.freebsd.org/cgi/query-pr.cgi?pr=155873). Ah Yes, that's the same problem. Thanks ! Can FreeBSD please revert the broken code out of CVS, until/ if author / importer / whoever might want to fix it. The new code breaks basic common functionality, to add rare usage exotica. I guess that reverting r205821 would mean reverting all of edwin's recent calendar(1) work (http://svnweb.freebsd.org/base/user/edwin/calendar/?view=log). Broken calendar code failed to mail prompt me to call meetings in time. Probably caused lots of missed reminders. There is also another recent calendar(1) regression: http://www.freebsd.org/cgi/query-pr.cgi?pr=157718 Edwin, please comment if you plan to take a look at these regressions. -- Jaakko ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Fwd: Add xdr_sizeof() support?
As per request, forward this message to hackers@. Original Message Date: Fri, 08 Jul 2011 14:54:33 +0800 From: Kevin Lo ke...@freebsd.org To: develop...@freebsd.org Subject: Add xdr_sizeof() support? Hi, We've had a function implementation for xdr_sizeof(3), but never added in libc. NetBSD imported our xdr_sizeof() into their libc: http://mail-index.netbsd.org/source-changes/2011/07/04/msg024213.html I was just wondering if there was a particular reason not to add it? Kevin ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Capsicum project: Ideas needed
[CCing Ben, Robert and Jonathan as it's very important for me to receive their feedback about my thoughts] Let me focus on those application ideas that you've mentioned. All the following are my thoughts and this may be incorrect, in this case please correct me. -any server software Yes, server software is a good candidate for bringing cap.mode in. Though this applies to servers that do not include in-process support for interpreters (ie Apache + mod_php), see later why. Such software as nginx, lighttpd is OK. Speaking about base system components, this list includes inetd daemons (but modification of inetd itself is NOT sufficient and ineffective, capability support implies modifying code of daemons) -any interpreter (perl, python, etc)? Proper capsicumization of these things requires heavy code hacking, and probably won't be accepted by upstream anyway, until Capsicum becomes a standard not only for BSD world. Should hold on for now. -any shell?... Processes that are started by the shell will inherit its capabilities. So this is undesirable IMHO. We should modify applications themselves. minicom wget curl links/lynx This is Ports software, we may try to modify it and even send patches to upstream, or maintain our local patches. I wanted to focus on base system components during GSoC, but it doesn't hurt to try to capsicumize these tools either. netcat We have it in base system, will look at it. From your first email: How about sendmail and bind? I don't know how many people actually use sendmail in base system? Regarding bind -- it's a good idea, though bind already includes support for running in jail AFAIK. Thank you for your feedback! On Fri, July 8, 2011 8:21 am, Matt wrote: I'm not too familiar with the operation of capsicum, but in general anything with untrusted (including in many cases user) input can be worth sandboxing, especially in a server environment. Obviously server processes themselves are often worth restricting to things like jails or vms etc., so sandboxing could be an alternative. I can also see cases where interpreters, database server software, and file viewers/editors could be sandboxed to prevent exploits from running away with the system via the exploited process. Especially in server environment, 'sudo less /var/log/evillogwithlessexploit' and kablooey. Admins may have to run user software, or non suid, executables which nonetheless receive the admin's elevated permissions. Call them usid, user set id, I suppose. Not the best, but it happens, especially when things need to work an hour ago. A few ideas along those lines: -any server software -any interpreter (perl, python, etc)? -any shell?... minicom wget curl netcat links/lynx Can it be made a switch on sudo? sudo --sandbox=someprofile,option tcpdump -tti pflog0 Hopefully I'm not missing the boat and these ideas are applicable :) Matt ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org !DSPAM:4e168c7810433083710550! -- Regards, Ilya Bakulin http://kibab.com xmpp://kibab...@jabber.ru ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Capsicum project: Ideas needed
On 8 Jul 2011, at 05:02, Matt Olander wrote: What about inetd? Is that possible or does each service it support need sandboxing, too? How about sendmail and bind? I'm less concerned about the core connection juggling content of inetd than the external services it launches -- however, inetd has a number of built-in services that do interpret and manipulate untrustworthy data (even if only in basic ways), and directly sandboxing them with Capsicum would be very useful. I'd also like to see some focus on network command line tools -- especially things like dig, ping, finger, host, etc, which tend to not need access to things after some threshold moment, and/or can motivate compartmentalisation work on libraries such as the resolver. At this point we should go for easy wins with 100% correctness. (Getting a version of the resolver working with sandboxed Capsicum stuff seems like a priority: it's a known issue with our sandboxed tcpdump, so modifying lwresd or similar so it can work with UNIX domain sockets, and teaching the resolver code to use them, would be excellent.) Robert___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Capsicum project: Ideas needed
On 08/07/2011 05:42, Ilya Bakulin wrote: Hi hackers, As a part of ongoing effort to enhance usage of Capsicum in FreeBSD base system, I want to ask you, which applications in the base system should receive sandboxing support. How about a small description what sandboxing can bring to applications? I'm browsing the documents at http://www.cl.cam.ac.uk/research/security/capsicum/documentation.html but it looks like it still mostly describes the generic framework rather than what you can do with it. From it, it looks like you can set limits on file handle operations (e.g. (lc_limitfd(STDOUT_FILENO, CAP_FSTAT | CAP_SEEK | CAP_WRITE)), but what else? ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Capsicum project: Ideas needed
On 8 July 2011 12:09, Ilya Bakulin webmas...@kibab.com wrote: modification of inetd itself is NOT sufficient and ineffective, capability support implies modifying code of daemons Speaking as someone who isn't terribly familiar with inetd: One could imagine inetd (or an inetd-like service) accepting connections, wrapping them up with capability rights masks, and forking capability-mode daemons that can't e.g. reconnect a socket. See comments about unmodified binaries, below. -any interpreter (perl, python, etc)? Proper capsicumization of these things requires heavy code hacking, and probably won't be accepted by upstream anyway, until Capsicum becomes a standard not only for BSD world. Should hold on for now. Fair enough. I think the language-level things are probably a better target for CTSRD, whose vocabulary includes fine-grained memory regions, rather than (relatively coarse) files and processes. -any shell?... Processes that are started by the shell will inherit its capabilities. So this is undesirable IMHO. We should modify applications themselves. Do take a look at https://github.com/trombonehero/capsh, which is a (not-fully-functional-as-a-shell-yet) capability-aware shell. It executes child processes in capability-mode sandboxes, providing access to explicitly named resources via library preloading (replacing the regular open() and friends, which will die with ECAPMODE, with versions that search through a list of explicitly inherited files). The philosophy is a bit like Plash, but the details are built on Capsicum foundations. As I said, I wouldn't call it functional yet, but it does allow me to run simple binaries, e.g. cat, unmodified but in a sandbox. So while I agree that it's good to modify applications to take advantage of Capsicum, there is some exploration to be done in bringing Capsicum-backed security improvements to unmodified applications. minicom wget curl links/lynx This is Ports software, we may try to modify it and even send patches to upstream, or maintain our local patches. I wanted to focus on base system components during GSoC, but it doesn't hurt to try to capsicumize these tools either. From your first email: How about sendmail and bind? I don't know how many people actually use sendmail in base system? Regarding bind -- it's a good idea, though bind already includes support for running in jail AFAIK. Both of these do seem like ideal candidates. Jail support is actually a plus: it means that some of the compartmentalization work might already be done for you, and provides a comparison point (evaluation with Jail, Capsicum and Jail+Capsicum). Can it be made a switch on sudo? sudo --sandbox=someprofile,option tcpdump -tti pflog0 Interesting... this starts to sound a bit like Mac OS X's sandbox policy files (run this binary, constrained by policy X.sb). I think that the capsh/Plash approach is a more natural fit for capabilities (policy files fit nicely with MAC), and indeed, a more natural tool for the job we're trying to do here. Perhaps 'sudo --sandbox command infile:r outfile:rw' could do something very much like what capsh tries to do. Jon -- Jonathan Anderson Research Student, Security Group Computer Laboratory University of Cambridge +44 (1223) 763747 jonathan.ander...@cl.cam.ac.uk ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: [PATCH] avoid assuming MAXPATHLEN in config(8)
2011/7/7 Ed Schouten e...@80386.nl:
Considering that the function is rather small anyway, why not compile it
in unconditionally (though having a different name).
Hi Ed,
I made the adjustment you requested, plus a bit more polishing
(plugged a memleak, etc), and then I hit what seems like a memory
corruption heisenbug.
I haven't been able to determine whether my patch introduces this bug
or it just uncovers it. As for now please disregard my request untill
I have time to debug this properly.
Thanks
--
Robert Millan
=== modified file 'config.h'
--- config.h2011-07-07 13:59:05 +
+++ config.h2011-07-07 14:06:28 +
@@ -199,7 +199,7 @@
extern int maxusers;
extern char *PREFIX; /* Config file name - for error messages */
-extern char srcdir[]; /* root of the kernel source tree */
+extern char *srcdir; /* root of the kernel source tree */
#define eq(a,b)(!strcmp(a,b))
#define ns(s) strdup(s)
=== modified file 'main.c'
--- main.c 2011-07-07 13:59:05 +
+++ main.c 2011-07-07 17:51:39 +
@@ -71,8 +71,8 @@
#defineCDIR../compile/
char * PREFIX;
-char destdir[MAXPATHLEN];
-char srcdir[MAXPATHLEN];
+char * destdir;
+char * srcdir;
intdebugging;
intprofiling;
@@ -122,8 +122,8 @@
printmachine = 1;
break;
case 'd':
- if (*destdir == '\0')
- strlcpy(destdir, optarg, sizeof(destdir));
+ if (destdir == NULL)
+ destdir = strdup(optarg);
else
errx(EXIT_FAILURE, directory already set);
break;
@@ -165,14 +165,13 @@
err(2, %s, PREFIX);
yyfile = PREFIX;
}
- if (*destdir != '\0') {
+ if (destdir != NULL) {
len = strlen(destdir);
while (len 1 destdir[len - 1] == '/')
destdir[--len] = '\0';
get_srcdir();
} else {
- strlcpy(destdir, CDIR, sizeof(destdir));
- strlcat(destdir, PREFIX, sizeof(destdir));
+ (void) asprintf(destdir, %s%s, CDIR, PREFIX);
}
SLIST_INIT(cputype);
@@ -230,6 +229,27 @@
}
/*
+ * xrealpath
+ * realpath() with extension to use malloc() when resolved is NULL.
+ */
+static char *
+xrealpath(const char *name, char *resolved)
+{
+#ifdef MAXPATHLEN
+ if (resolved == NULL) {
+ resolved = malloc(MAXPATHLEN);
+ if (realpath(name, resolved) == NULL) {
+ free(resolved);
+ resolved = NULL;
+ }
+ } else
+#endif
+ resolved = realpath(name, resolved);
+
+ return resolved;
+}
+
+/*
* get_srcdir
* determine the root of the kernel source tree
* and save that in srcdir.
@@ -241,7 +261,9 @@
char *p, *pwd;
int i;
- if (realpath(../.., srcdir) == NULL)
+ if (srcdir != NULL)
+ free(srcdir);
+ if ((srcdir = xrealpath(../.., NULL)) == NULL)
err(EXIT_FAILURE, Unable to find root of source tree);
if ((pwd = getenv(PWD)) != NULL *pwd == '/'
(pwd = strdup(pwd)) != NULL) {
@@ -254,9 +276,12 @@
*p = '\0';
}
if (stat(pwd, lg) != -1 stat(srcdir, phy) != -1
- lg.st_dev == phy.st_dev lg.st_ino == phy.st_ino)
- strlcpy(srcdir, pwd, MAXPATHLEN);
- free(pwd);
+ lg.st_dev == phy.st_dev lg.st_ino == phy.st_ino) {
+ free(srcdir);
+ srcdir = pwd;
+ } else {
+ free(pwd);
+ }
}
}
@@ -386,9 +411,9 @@
char *cp = NULL;
if (file)
- asprintf(cp, %s/%s, destdir, file);
+ asprintf(cp, %s/%s, destdir ? destdir : , file);
else
- cp = strdup(destdir);
+ cp = strdup(destdir ? destdir : );
return (cp);
}
=== modified file 'mkmakefile.c'
--- mkmakefile.c2011-07-07 13:59:05 +
+++ mkmakefile.c2011-07-07 14:12:06 +
@@ -152,7 +152,7 @@
fprintf(ofp, DEBUG=-g\n);
if (profiling)
fprintf(ofp, PROFLEVEL=%d\n, profiling);
- if (*srcdir != '\0')
+ if (srcdir != NULL)
fprintf(ofp,S=%s\n, srcdir);
while (fgets(line, BUFSIZ, ifp) != 0) {
if (*line != '%') {
@@ -304,9 +304,9 @@
}
static void
-read_file(char *fname)
+read_file(const char *fname)
{
- char ifname[MAXPATHLEN];
+ char *ifname;
FILE *fp;
struct file_list *tp;
struct device *dp;
@@ -349,8 +349,9 @@
fname);
Re: Capsicum project: Ideas needed
On 07/08/2011 05:42 AM, Ilya Bakulin wrote: The question is: which applications should also be processed? I think that the most wanted candidates are SUID programs and/or popular network daemons. But looking at gzip example I also think about text-processing tools in general. I think tcpdump (and wireshark, but that's a port) may be a good candidate. -- Pieter ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Capsicum project: Ideas needed
FWIW; I would think ftpd, which may require an update too, would be a classical candidate. Perhaps also telnetd. I recall sendmail calls bin/sh for some things and there is an option for a restricted shell (rsh), so supporting a shell would help sendmail too. And then some stuff like ipfw is never too security aware. However for those of us not capsicum-aware it's difficult to say if using jails would be better or more practical. cheers, Pedro. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Capsicum project: Ideas needed
On Fri, Jul 08, 2011 at 07:42:12AM +0400, Ilya Bakulin wrote: The question is: which applications should also be processed? I think that the most wanted candidates are SUID programs and/or popular network daemons. I propose 'man'; sneaky stuff can happen there Dunno if that meshes with your focus on servers, though... -- Regards, Ilya Bakulin http://kibab.com xmpp://kibab...@jabber.ru -- Brian Reichert reich...@numachi.com BSD admin/developer at large ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Include file search path
Hi, On Sat, Jun 25, 2011 at 2:01 PM, Arnaud Lacombe lacom...@gmail.com wrote: Hi, On Mon, Jun 6, 2011 at 5:37 PM, Arnaud Lacombe lacom...@gmail.com wrote: Hi, On Tue, May 31, 2011 at 12:23 PM, Warner Losh i...@bsdimp.com wrote: On May 22, 2011, at 9:48 PM, Arnaud Lacombe wrote: Hi Warner, On Sat, Apr 2, 2011 at 6:49 PM, Warner Losh i...@bsdimp.com wrote: On Apr 2, 2011, at 1:10 PM, Robert N. M. Watson wrote: On 2 Apr 2011, at 19:47, Warner Losh wrote: (2) Working clang/LLVM cross-compile of FreeBSD. This seems like a basic requirement to adopt clang/LLVM, and as far as I'm aware that's not yet a resolved issue? 0 work has been done here to my knowledge. The world view for clang and our in-tree gcc differ which makes it a challenge. That's disappointing. I seem to recall it's more an issue of our build integration with clang/LLVM than an underlying issue in clang/LLVM? Yes. The problem isn't hard, the cross compile paradigm is just a little different. We (Cambridge) are currently bringing up FreeBSD on a new soft-core 64-bit MIPS platform. We're already using a non-base gcc for our boot loader work, and plan to move to using clang/LLVM later in the year. The base system seems a bit short on detail when it comes to the above, currently. Yes. I've had to add about a dozen changes so far to get close to building with xdev compilers. A similar number are needed to make it easy to configure and add systree support, I think. Sounds like great progress -- do you think we'll ship 9.0 in a just works state with regard to this? I sure hope so. I'd like to have demoable stuff by BSDcan. BSDCan has passed, has there been any advance made since that discussion ? It is demonstrable but not ready to commit to the tree. Needs about 4 hours of work that I've had trouble scheduling on it due to work getting busier than I expected. any chances to have a look at the patch or should I wait for the final commit ? ping ? ping ? - Arnaud ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Capsicum project: Ideas needed
On 8 Jul 2011, at 19:08, Brian Reichert wrote: On Fri, Jul 08, 2011 at 07:42:12AM +0400, Ilya Bakulin wrote: The question is: which applications should also be processed? I think that the most wanted candidates are SUID programs and/or popular network daemons. I propose 'man'; sneaky stuff can happen there Dunno if that meshes with your focus on servers, though... This seems like a perfect example of something that wants to be sandboxed, especially in a post-nroff mandoc world where a single C binary can be sandboxed. Robert___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
