Re: Semantics of seteuid(uid) vs. setreuid(-1,uid)
On 2004-06-07 01:30 -0700, David Schultz [EMAIL PROTECTED] wrote: On Sun, Jun 06, 2004, Stefan Eer wrote: Any reason, that there is a difference in semantics between: seteuid(id) vs. setreuid(-1, id)??? The tests performed on the arguments are different (assuming a fixed arg of -1 for ruid) in that seteuid does not support the case of (euid == cr_uid): [...] Is the difference between seteuid() and setreuid() deliberate ? The best rationale I can think of is that setreuid(x, geteuid()) does something useful, whereas seteuid(geteuid()) is a no-op. I think the seteuid() behavior you complain about exists for purely historical reasons. POSIX does not require seteuid(geteuid()) to succeed, but it implicitly allows it as an extension. Solaris and Linux have this extension. The trouble with tweaking the interface is that you always have to ask: what new security holes could this open up in existing software? Thanks for the reply. I'm afraid that there might be security risks and/or broken programs in the system. Problem is, that the current behaviour breaks programs in ports, that expect seteuid to behave the same as setreuid(-1,uid) does on FreeBSD. But this can be fixed in the individual ports ... Hao Chen points out that the failure of seteuid(geteuid()) in FreeBSD is one of many tricky issues with using the set*uid() interface portably. In my (biased) opinion, his Setuid Demystified paper, is well worth reading if you want to untangle this stuff in your mind: http://www.usenix.org/events/sec02/full_papers/chen/chen.pdf Thank you for the pointer: Interesting reading ! Regards, STefan ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Semantics of seteuid(uid) vs. setreuid(-1,uid)
Any reason, that there is a difference in semantics between: seteuid(id) vs. setreuid(-1, id)??? The tests performed on the arguments are different (assuming a fixed arg of -1 for ruid) in that seteuid does not support the case of (euid == cr_uid): seteuid(euid): euid != oldcred-cr_ruid euid != oldcred-cr_svuid setreuid(-1, euid): euid != oldcred-cr_uid euid != oldcred-cr_ruid euid != oldcred-cr_svuid So seteuid() may fail in cases where setreuid() with a first argument of -1 succeeds. The test obviously corresponds to POSIX appendix B.4.2.2 as mentioned in the comment in setuid(). Is the difference between seteuid() and setreuid() deliberate ? I'm asking because I have received a bug report for a port, and it appears that seteuid() on other systems is indeed equivalent to our setreuid(-1,). Regards, STefan ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Where is FreeBSD going?
On 2004-01-09 11:38 -0600, Sean Farley [EMAIL PROTECTED] wrote: I admit to having not tried it, but I wonder how well OpenCM (http://www.opencm.org/) would compare. I think it would have a smaller footprint than Subversion. I have prepared a port of OpenCM, but didn't have time to test it, yet. For that reason, I have not yet imported it into the ports repository. Just in case somebody wants to test OpenCM (or my port ;-) Regards, STefan ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: secure file flag?
On 2003-11-23 17:31 +0100, Dag-Erling Smørgrav [EMAIL PROTECTED] wrote: Stefan Eßer [EMAIL PROTECTED] writes: What I'm suggesting is to have the obliteration implemented as an add on to the dirty buffer flush, with the difference that the buffer contents is prepared for the next step of the erasure process, written out, and then not declared free but again prepared for the next overwrite pass. This next pass won't be until thirty seconds later, so it'll take about half an hour to completely obliterate a file. Furthermore, These 30 seconds are not a universal constant and ISTR. I had in mind, that one obliteration pass is performed. After each pass, a cache flush has to be performed, and the next pass is performed immediately or only after a brief delay. I see, that this may cause too many CPU cycles spent traversing the buffer cache. unmounting a file system less than half an hour after a file is deleted or truncated will fail, and shutting down will most likely leave the file system unclean due to repeated failures to flush the dirty buffer list. Yes, that's why I meant that fsck might be used to trigger the restart of an erasure process that was not completed due to shutdown or a crash. This does obviously no good in case that somebody else got hold of your disk, menawhile, but it covers cases that are not dealt with by a user-land utility (which would just be stopped halfway through when the system goes down). Regards, STefan ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: secure file flag?
On 2003-11-23 18:04 +0100, Poul-Henning Kamp [EMAIL PROTECTED] wrote: 1. Look for BIO_DELETE in the kernel. Seems that BIO_DELETE isn't really supported anymore (according to a comment in your GEOM sources ;-) AFAICT, BIO_DELETE can't easily be made a long running operation (taking tens of revolutions of a disk media) without really hurting performance because of assumptions that it will take about the same time as BIO_WRITE ... 2. Use GBDE or other encryption. Yes, probably. But encryption is only as good as key management and secure storage (and deletion) of keys. How do you implement unattended reboot, if you consider unauthorized (physical) access to your system as one of the attack scenarios to protect against ? (Not meaning, that secure erase would really solve that problem ...) Regards, STefan ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: secure file flag?
On 2003-11-23 10:11 -0800, Wes Peters [EMAIL PROTECTED] wrote: Encrypting data and secure removal of data are orthogonal and in case you need one, the other propbably won't be a good choice. Both are completely adequate to protect the data on the disk from disclosure. Yes, if effective. Encryption protects as long as the keys are unknown to the attacker, secure removal protects as long as the data is overwritten before the attacker tries to get access. I'm sure you know that ... fsck could identify incompletely erased (in the sense of multipass overwrite with specific patterns) blocks, if that state was marked in the inode. But if someone is attempting to recover your deleted data, they're not going to run tools that would potentially eliminate that data from the disk. I'm designing to the idea of a disk that has been physically taken to a data recovery lab, because the intermediate steps don't interest me. But you see that: Thanks! I'm getting more convinced that there might a chance to communicate, now ;-) This is not meant as protection in case power is removed and the disk is analyzed off-line since most probably no fsck will ever be run over the filesystem again. The data needs to be overwritten in a timely manner as well. Leaving the disk in a partly erased state is the same as leaving it unerased. If you don't want the processing delay needed to do the full erasure you obviously don't really need full erasure. Yes. That's why encryption can be required. It protects data from the instant the clear-text has vanished (from RAM or some media). Secure deletion can't provide that! But there may still be situations, where you want to securely erase data from a medium. Either because that medium contained sensitive plain text or because it contained key data, for example (which is just another kind of sensitive plain text, in a way ;-) In that case, a small window of wulnerability may be tolerable (at least in a commercial environment). Encryption promises to keep existing data secret, and that promise may be broken. But in case you still need that data, you don't have much choice. Deleting it will not be an option. Secure erase gets rid of that data, and you don't have to worry that anybody may get hold of some kind of access key, once it's gone (which may take some time and effort to achieve, and that's what started this thread). Again: Nothing new to you ... It is meant to protect against a power failure (or reboot) with data not being erased according to the specification, which might survive for a long time after next start (not by an attacker but in normal service). This is extra paranoia (compare to a crash while obliterate is overwriting blocks, which will not be restarted after a crash ...) It seems that you are opposed to having secure erase support in the kernel, and in fact, I'm not sure it is that useful, myself. No, at one time I had it on my todo list, but came to a more full understanding of the expense and abadoned it for that reason. I may someday do it in the simplest form just to prove it workable to myself, but I doubt that is a solution of general interest to FreeBSD. Ok. I've also thought some about this, and I think that different media might need different methods (i.e. MFM vs. RLL vs. PRML, but also vs. Flash media). High density disks (ATA more than SCSI, actually) seem to make it much harder to recover remains of overwritten data, and it may in fact be acceptable to perform just a few passes with random data (as suggested by Peter Gutmann, 7 years ago, when areal densities were one to two orders of magnitude lower than today ...) But in case it is considered useful and implemented (I'd try it myself, if I was interested in using this feature), then we should discuss the techical (and security) aspects of several designs and that's what I'm trying to do. There is some merit in providing a mechanism that is 90% as secure at 10% the computational cost. I basic infrastructure that provides a secure removal flag at the file and/or filesystem layer and a choice of patterns would be a nice solution. Those who just want to make sure the contents of an email aren't inadvertantly disclosed to another user could specify a simple pattern like overwrite with zeros once, those who want to keep the FBI at bay could use the whole 37 passes and spend days deleting files. Maybe I'll look into this again after all. The former variant seems like it might even be useful for a mail server or similar application. The ability to specify different patterns seems useful. I'd consider a window of vulnerability of 10 seconds to one minute acceptable, and I guess this should be possible to acchive, even for nontrivial amounts of data that are to be deleted (40 passes at 1MB/s effective (including seeks) would impose a limit of 25KB/s per disk, while 8 passes at 4MB/s effective would
Re: secure file flag?
On 2003-11-24 12:20 +0100, Dag-Erling Smørgrav [EMAIL PROTECTED] wrote: Stefan Eßer [EMAIL PROTECTED] writes: Ok. I've also thought some about this, and I think that different media might need different methods (i.e. MFM vs. RLL vs. PRML, but also vs. Flash media). PRML is not an encoding scheme like MFM or RLL, it is an algorithm for recovering a bitstream from a weak analog signal. Modern disks mostly use RLL encoding. So what? PRML is not complementary to RLL. RLL is typically used to mean 1,7 RLL offering a 2/3 coding, while PRML starts at 8/9 and current devices use up to 24/25 (i.e. 24 bits in 25 channel bits). MFM can be considered a special case of RLL encoding, too, BTW ... But it's utterly irrelevant, that PRML data is written to disk as an RLL encoded data stream. What matters is what can be read back from the disk media (and PRML is about reading, not writing ;-) You probably don't want to claim that 1,7 RLL and a modern PRML encoding can be decoded with similar effort ... And that is what this thread is about: Secure removal of data from storage media. There definitely is a difference between RLL (as in 1,7i RLL) and modern PRML drives under this aspect. Regards, STefan ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: secure file flag?
On 2003-11-23 00:16 -0800, Wes Peters [EMAIL PROTECTED] wrote: On Friday 21 November 2003 03:56 pm, Stefan Eßer wrote: A simple algorithm could just mark each buffer with a special kind of dirty flag and a counter for the pass number (in fact, the existing dirty flag could be used, and a counter set to the number of passes required, with 0 indicating that the buffer is to be flushed to disk as is in the normal way). Oh, but you're wrong, if you actually want to ERASE the data on the disk platters. That's why I've referred people to the obliterate program in ports several times. Read the references contained there, then come back to this discussion. This is rude! It's been some time since I read the Gutmann paper, but I still remember the points he made and even quite a number of the details. Either my (English) language skills are insufficient to make my point, or you just didn't read what I wrote. I thought it was obvious that if I'm talking of several passes, that each one writes specific data (either a complement of the original data, a suitable pattern or random data). What I'm suggesting is to have the obliteration implemented as an add on to the dirty buffer flush, with the difference that the buffer contents is prepared for the next step of the erasure process, written out, and then not declared free but again prepared for the next overwrite pass. A counter is required to keep the required state information for each individual buffer. AFAIK, there is no need to retain original data (or its complement) for the process, so in fact all that is needed is a pass counter and the very simple FA. There is no need for a special thread, and that was the point I was trying to make. Takling of obliterate: There is the patterns[] array and the passno variable attached to a buffer could select one of those patterns on each pass of the elevator. (Well, may be a seperate thread might be better to prepare buffers by filling in the correct patterns at slightly reduced priority ...) If you just want to zero the blocks, that is a lot easier, but you're not really protecting anything from anyone who can get their hands on the disk. Who is talking about just zeroing blocks ? Please take the time to actually read the messages you reply to ... Regards, STefan ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: secure file flag?
On 2003-11-23 00:19 -0800, Wes Peters [EMAIL PROTECTED] wrote: On Saturday 22 November 2003 02:54 am, Stefan Eßer wrote: On 2003-11-22 11:04 +0100, Dag-Erling Smørgrav [EMAIL PROTECTED] wrote: Stefan Eßer [EMAIL PROTECTED] writes: I may be way off, but I do not think, that a special thread or a cache flush after each block is required: [...] What happens if you yank the power cord? Worst case: The same thing that happened, if the you lost power a fraction of a second earlier, just before the unlink or loss of last reference to the file ... Nothing short of a self-destruct mechanism will do any better ;-) Poppycock. Encrypting the data before it hits the disk is a fine protection against somebody later recovering the data, either inadvertantly or nefariously. Aren't we again unneccessarily rude here ? Encrypting data and secure removal of data are orthogonal and in case you need one, the other propbably won't be a good choice. In doubt, I'd use encyption at the disk block level to protect sensitive data, but that's not the topic of this thread, IIRC. The subject was to get rid of remnants of data (whether encrypted or not) from some magnetic media (and similar methods might be suitable for flash media with different patterns and a smaller number of passes). Back to the subject of this thread: You could write a special flag needs to be securely removed to the inode. That way, an interrupted overwrite process could be continued after next reboot (for example initiated by fsck). But why would somebody trying to steal your data run fsck on it? You're not thinking paranoid enough. Sorry, but what are you talking about ? fsck could identify incompletely erased (in the sense of multipass overwrite with specific patterns) blocks, if that state was marked in the inode. This is not meant as protection in case power is removed and the disk is analyzed off-line since most probably no fsck will ever be run over the filesystem again. It is meant to protect against a power failure (or reboot) with data not being erased according to the specification, which might survive for a long time after next start (not by an attacker but in normal service). This is extra paranoia (compare to a crash while obliterate is overwriting blocks, which will not be restarted after a crash ...) It seems that you are opposed to having secure erase support in the kernel, and in fact, I'm not sure it is that useful, myself. But in case it is considered useful and implemented (I'd try it myself, if I was interested in using this feature), then we should discuss the techical (and security) aspects of several designs and that's what I'm trying to do. Regards, STefan ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: secure file flag?
On 2003-11-22 11:04 +0100, Dag-Erling Smørgrav [EMAIL PROTECTED] wrote: Stefan Eßer [EMAIL PROTECTED] writes: I may be way off, but I do not think, that a special thread or a cache flush after each block is required: [...] What happens if you yank the power cord? Worst case: The same thing that happened, if the you lost power a fraction of a second earlier, just before the unlink or loss of last reference to the file ... Nothing short of a self-destruct mechanism will do any better ;-) (You could provide an internal UPS and try to prevent unauthorized access to hardware components by sealing the components in a special enclosing, but I guess we are getting carried away. Better protect against unauthorized access to the computer and have it emergency shutdown (with secure deletion of critical information) in case of a (physical :) access violation. Back to the subject of this thread: You could write a special flag needs to be securely removed to the inode. That way, an interrupted overwrite process could be continued after next reboot (for example initiated by fsck). This is meant to protect against traces of sensible data being left on the disk for a long time after a crash. But such an inode would also indicate to an attacker the disk blocks that where considered needing protection and may make an attack at the magnetic residue practical at all ... But the real problem appears to be, when to mark the blocks and inode as free. Normally, the blocks are returned to the free block map when an inode is invalidated. File system blocks may not be reused, before the overwrite procedure has completed. Again, this requires that the inode is only removed after the last file block has been processed. But I'm not sure whether there is a mechanism that allows invalidating the inode after the last associated buffer has been flushed ... Regards, STefan ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: secure file flag?
On 2003-11-21 14:09 -0800, Wes Peters [EMAIL PROTECTED] wrote: As for performance, you really need to flush the on-device cache on each pass to make sure the bit patterns get written to the platter in proper order. I don't see any clever way to coalesce the writing of the various patterns to multiple blocks short of a kernel thread, either, so performance would be abysmal. Imagine removing a large file, overwriting each block in 37 (IIRC) passes, syncing all the way through the on-disk cache after *every block.* I may be way off, but I do not think, that a special thread or a cache flush after each block is required: A simple algorithm could just mark each buffer with a special kind of dirty flag and a counter for the pass number (in fact, the existing dirty flag could be used, and a counter set to the number of passes required, with 0 indicating that the buffer is to be flushed to disk as is in the normal way). All blocks belonging to the file must be read from disk, if not already present in some buffer, for the erasure process to start. (See below for large files.) In preparation of the first pass, the data in the buffer could be complemented and then written back to disk as in a normal dirty buffer flush. After some block has been written, its counter will be updated and the block will still be marked dirty, until the number of passes required to consider the data irrecoverable has been reached. (Blocks that had the counter set to 0 at the start of the flush are normal writes and need not be considered, here.) On successive passes, the block can be overwritten with specific bit patterns or random data according to some procedures for secure erasure of data from magnetic media. On each turn of the elavator algorithm, a cache flush is initiated, if the previous path included at least one buffer with the secure erase flag set. (Any number of unrelated reads or writes could have been executed during this path of the elevator.) After the specified number of iterations, the individual block will be marked as free and can be put into the free list. Until then, it can not be accessed or reclaimed. That way, the normal operation of the disk would not be impacted. On each pass of the elevator algorithm, each buffer flagged to be securely erased will be written once and its state will be updated. No special cleaner thread is required, just a byte for the counter. The biggest problem could be the first step of the algorithm (to read all file blocks into buffers that are marked dirty and get the number of the first erasure pass assigned). But I guess, that the erasure of long files could be broken in several parts, that each fit into the RAM available for buffers. Only this case would require that the unlink or process exit be delayed until the last part of the file has been read in and marked dirty and to be overwritten. Regards, STefan ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: md5(1) exit code
On 2003-10-12 16:50 +0100, Colin Percival [EMAIL PROTECTED] wrote:
Or rather, lack thereof. I was rather astonished to find that `md5
/nonexistant` printed an error message but still returned an exit code of
zero; this is, of course, due to the use of warn() instead of err() in
response to a receiving a NULL pointer returned from MD5File(3).
Is there any reason for this behaviour?
Don't think so, and I fixed it many years ago (much earlier
than the dates in the diff seem to indicate) on my system.
Patch attached ...
Regards, STefan
PS: Guess I should just commit this change to -current ...
Index: md5.1
===
RCS file: /usr/cvs/src/sbin/md5/md5.1,v
retrieving revision 1.18
diff -u -r1.18 md5.1
--- md5.1 19 Apr 2002 23:05:25 - 1.18
+++ md5.1 21 Jun 2002 12:53:47 -
@@ -67,6 +67,10 @@
.It Fl x
Run a built-in test script.
.El
+.Sh DIAGNOSTICS
+The
+.Nm
+program exits 0 on success, and 1 if at least one of the input files could not be
read.
.Sh SEE ALSO
.Xr cksum 1
.Rs
Index: md5.c
===
RCS file: /usr/cvs/src/sbin/md5/md5.c,v
retrieving revision 1.30
diff -u -r1.30 md5.c
--- md5.c 3 May 2003 18:41:58 - 1.30
+++ md5.c 4 May 2003 13:11:55 -
@@ -62,7 +62,9 @@
int ch;
char *p;
charbuf[33];
+ int failed;
+ failed = 0;
while ((ch = getopt(argc, argv, pqrs:tx)) != -1)
switch (ch) {
case 'p':
@@ -93,19 +95,24 @@
if (*argv) {
do {
p = MD5File(*argv, buf);
- if (!p)
+ if (!p) {
warn(%s, *argv);
- else
+ failed++;
+ } else {
if (qflag)
printf(%s\n, p);
else if (rflag)
printf(%s %s\n, p, *argv);
else
printf(MD5 (%s) = %s\n, *argv, p);
+ }
} while (*++argv);
} else if (!sflag (optind == 1 || qflag || rflag))
MDFilter(0);
+ if (failed != 0)
+ return (1);
+
return (0);
}
/*
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Broadcom 440x support?
There are Linux drivers available for download and it seems, that the 440x and 520x drivers are very similar. I intended to make the bge driver support the 440x in my ASUS A7K8X, but have not had time to actually start that project (beyond the initial diff of the two official drivers.) If anybody is interested, I can provide the diffs, which amount to 2620 lines (diff -u1). But many differences are cosmetic (b44_ prepended to function names and bcm5700 replaced by bcm4400 in many identifiers). The actual driver change will probably amount to just a few hundred lines, at most ... Regards, STefan On 2003-02-21 13:58 -0800, Julian Elischer [EMAIL PROTECTED] wrote: We just got 40 of them... answer.. no :-( On Fri, 21 Feb 2003, Lars Eggert wrote: we just got an Asus P4PE board with a Broadcom 440x NIC on it - is there any driver that supports it yet? To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
