Re: Hardlinks...
Crist J. Clark wrote: On Mon, Apr 08, 2002 at 09:13:12PM -0700, Terry Lambert wrote: [snip] It's arguable that / and /usr themselves should be mounted read-only, It's not very practical to have / read-only on a truely multi-user (the only time this linking stuff is much of an issue) 4-STABLE system. The two main reasons being /etc/master.passwd, et al, and the problems with a read-only /dev. It takes extensive customizations and kludges to get this to work. Actually, with minimal work in the rc.diskless* files, we have a very workable, large-scale system with / as Read-Only. In fact, only /dev and /var are read-write (well, in testing we also have a /sewer for coredumps) /dev and /var are local RAM disks (and /tmp points are /var/tmp) One of these days I will want to write up some of what we did. It really is rather nice to have a whole cluster of machines sharing the same install and the boot server. -- Michael Sinz Worldgate Communications [EMAIL PROTECTED] A master's secrets are only as good as the master's ability to explain them to others. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Hardlinks...
On Thu, Apr 18, 2002 at 11:18:30AM -0400, Michael Sinz wrote: Crist J. Clark wrote: On Mon, Apr 08, 2002 at 09:13:12PM -0700, Terry Lambert wrote: [snip] It's arguable that / and /usr themselves should be mounted read-only, It's not very practical to have / read-only on a truely multi-user (the only time this linking stuff is much of an issue) 4-STABLE system. The two main reasons being /etc/master.passwd, et al, and the problems with a read-only /dev. It takes extensive customizations and kludges to get this to work. Actually, with minimal work in the rc.diskless* files, we have a very workable, large-scale system with / as Read-Only. In fact, only /dev and /var are read-write (well, in testing we also have a /sewer for coredumps) /dev and /var are local RAM disks (and /tmp points are /var/tmp) It may be easier to fit it in with a diskless configuration. One of the problems is that in a normal (i.e. not diskless) stuff in /dev is used before you get at chance to mount something over /dev. And that may or may not be a problem. But the diskless stuff is run so early in the boot process, it seems like it should be easier to manage that. One of these days I will want to write up some of what we did. That would be interesting. -- Crist J. Clark | [EMAIL PROTECTED] | [EMAIL PROTECTED] http://people.freebsd.org/~cjc/| [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Hardlinks...
Crist J. Clark wrote: file is created in /etc; it does the right thing, if the symlink is read-only, though...). Exactly, you can't use symlinks with the passwd(1) and pwd_mkdb(8) commands as they stand. The commands will bail when they try to create a temporary file in /etc, /etc/pw.XX if /etc is read-only. If /etc is not read-only, the symlinks will get removed and the files actually written in /etc. it does the right thing, if the symlink is read-only, though... That includes if it's on a read-only FS... 8-). -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Hardlinks...
On Mon, Apr 08, 2002 at 09:13:12PM -0700, Terry Lambert wrote: [snip] It's arguable that / and /usr themselves should be mounted read-only, It's not very practical to have / read-only on a truely multi-user (the only time this linking stuff is much of an issue) 4-STABLE system. The two main reasons being /etc/master.passwd, et al, and the problems with a read-only /dev. It takes extensive customizations and kludges to get this to work. -- Crist J. Clark | [EMAIL PROTECTED] | [EMAIL PROTECTED] http://people.freebsd.org/~cjc/| [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Hardlinks...
Hi, At 11:41 08/04/02 -0700, Michael Smith wrote: On Mon, 8 Apr 2002, [ISO-8859-2] Pawe³ Jakub Dawidek wrote: Simple example why I think that only owner should have permission to create hardlinks to his files. ... I see you forgot to 'ls -l' the resultant link ... you'll find that it has the same permissions and ownership as the original file. Oops. You misunderstand the original poster's complaint. The issue is that a non-owner can cause the owner's file to remain alive even after the owner has deleted it. Hence the comment about later breakin. You could also use this technique to maliciously exhaust a user's quota, by linking to their temporary files. I'm not sure what the standards have to say about this, but I don't much like the current behaviour. If you have any permissions on the file, you can prolong its life without a link simply by having a process open it. This is 'better' as a DOS because it's harder to spot. -- Bob Bishop +44 (0)118 977 4017 [EMAIL PROTECTED]fax +44 (0)118 989 4254 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Hardlinks...
On Tue, 9 Apr 2002, Terry Lambert wrote: Crist J. Clark wrote: On Mon, Apr 08, 2002 at 09:13:12PM -0700, Terry Lambert wrote: [snip] It depends. If this is a truly multiuser environment, then you are probably getting your authentication from NIX or RADIUS. It's really arguable that /etc should be a nullfs mount off of somewhere else and/or variable information belongs in var or some other place... Sun has been able to do this since 1988 or so (at least). As terry knows of course, the Interjet had the following /etc/symlinks: (excuse linewrap) lrwxrwxrwx 1 root wheel 20 Mr 28 2001 crontab@ - /writable/system/crontab lrwxrwxrwx 1 root wheel 18 Mr 28 2001 group@ - /writable/system/group lrwxrwxrwx 1 root wheel 22 Mr 28 2001 localtime@ - /writable/system/localtime lrwxrwxrwx 1 root wheel 3 Mr 28 2001 malloc.conf@ - A lrwxrwxrwx 1 root wheel 26 Mr 28 2001 master.passwd@ - /writable/system/master.passwd lrwxrwxrwx 1 root wheel 19 Mr 28 2001 pwd.db@ - /writable/system/pwd.db lrwxrwxrwx 1 root wheel 28 Mr 28 2001 resolv.conf@ - /writable/server/dns/resolv.conf lrwxrwxrwx 1 root wheel 31 Mr 28 2001 sendmail.cf@ - /writable/mail/sendmail/sendmail.cf lrwxrwxrwx 1 root wheel 20 Mr 28 2001 spwd.db@ - /writable/system/spwd.db the single root+usr partition is mounted read-only. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Hardlinks...
Julian Elischer wrote: As terry knows of course, the Interjet had the following /etc/symlinks: (excuse linewrap) lrwxrwxrwx 1 root wheel 20 Mr 28 2001 crontab@ - /writable/system/crontab lrwxrwxrwx 1 root wheel 18 Mr 28 2001 group@ - /writable/system/group [ ... ] the single root+usr partition is mounted read-only. Yes, but appealing to a product I had something to do with, even if that organization wasn't mine in particular, makes a much less powerful argument. The other thing that's a bit painful about that argument is that the symlinks failed to operate as expected for the master.passwd, if the / was mounted read/write. I count this as a bug in the password database generation code, but it should be noted that it can be a problem (e.g the symlink is renamed to the backup, and the replacement file is created in /etc; it does the right thing, if the symlink is read-only, though...). 8-(. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Hardlinks...
On Tue, Apr 09, 2002 at 04:42:52PM -0700, Terry Lambert wrote: Julian Elischer wrote: As terry knows of course, the Interjet had the following /etc/symlinks: (excuse linewrap) lrwxrwxrwx 1 root wheel 20 Mr 28 2001 crontab@ - /writable/system/crontab lrwxrwxrwx 1 root wheel 18 Mr 28 2001 group@ - /writable/system/group [ ... ] the single root+usr partition is mounted read-only. Yes, but appealing to a product I had something to do with, even if that organization wasn't mine in particular, makes a much less powerful argument. The other thing that's a bit painful about that argument is that the symlinks failed to operate as expected for the master.passwd, if the / was mounted read/write. I count this as a bug in the password database generation code, but it should be noted that it can be a problem (e.g the symlink is renamed to the backup, and the replacement file is created in /etc; it does the right thing, if the symlink is read-only, though...). Exactly, you can't use symlinks with the passwd(1) and pwd_mkdb(8) commands as they stand. The commands will bail when they try to create a temporary file in /etc, /etc/pw.XX if /etc is read-only. If /etc is not read-only, the symlinks will get removed and the files actually written in /etc. -- Crist J. Clark | [EMAIL PROTECTED] | [EMAIL PROTECTED] http://people.freebsd.org/~cjc/| [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Hardlinks...
Hey... Why I can made hardlink to file that I'm not owner? Simple example why I think that only owner should have permission to create hardlinks to his files. First. leila:root:~# ls -l /root/very-secret-file -rw-- 1 root wheel 3011 13 Lut 16:47 /root/very-secret-file leila:evil-hacker:~ ln /root/very-secret-file ~/whatsthis I need remove it fast!!! leila:root:~# rm -f /root/very-secret-file Yes, I know that evil-hacker can't read this file but... He can't read it NOW, but in a future he can break in and read it. I know that we can check this with 'st_nlink' or use -P with rm, but... Or tell me when this feature can help. -- Pawe Jakub Dawidek Network Administrator. Am I Evil? Yes, I Am. msg33405/pgp0.pgp Description: PGP signature
Re: Hardlinks...
On Mon, Apr 08, 2002 at 11:41:44AM -0700, Michael Smith wrote: You could also use this technique to maliciously exhaust a user's quota, by linking to their temporary files. I'm not sure what the standards have to say about this, but I don't much like the current behaviour. The truely paranoid ftruncate the file size to zero if the link count is larger than one. -Kurt To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Hardlinks...
In the last episode (Apr 08), Kurt J. Lidl said: On Mon, Apr 08, 2002 at 11:41:44AM -0700, Michael Smith wrote: You could also use this technique to maliciously exhaust a user's quota, by linking to their temporary files. I'm not sure what the standards have to say about this, but I don't much like the current behaviour. The truely paranoid ftruncate the file size to zero if the link count is larger than one. .. or even if isn't, as someone might link it just before you delete it. An attacker can still exhaust your inode quota with 0-length files. I wonder if there is any reason to allow arbitrary hardlinking; maybe only allow linking of files you currently have read access to? Only files that you own? Only allow root to hardlink? How paranoid do you want to be? :) It could always be another sysctl knob. -- Dan Nelson [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Hardlinks...
On Mon, Apr 08, 2002 at 02:49:15PM -0500, Dan Nelson wrote: .. or even if isn't, as someone might link it just before you delete it. An attacker can still exhaust your inode quota with 0-length files. I wonder if there is any reason to allow arbitrary hardlinking; maybe only allow linking of files you currently have read access to? Only files that you own? Only allow root to hardlink? How paranoid do you want to be? :) It could always be another sysctl knob. I once wrote a patch to stop people making hardlinks to a file unless they were root or the file's owner. I ran with it for a bit and never noticed it being triggered. It probably should be a filesystem mount option, but we're out of them until the new mount code comes into use. David. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Hardlinks...
On Mon, Apr 08, 2002 at 11:41:44AM -0700, Michael Smith wrote:
+ You could also use this technique to maliciously exhaust a user's quota,
+ by linking to their temporary files. I'm not sure what the standards
+ have to say about this, but I don't much like the current behaviour.
+
Yes. And look on this part of foldinfo.c from procmail:
{ if(stbuf.st_uid!=uid|| /* recipient not owner */
!(stbuf.st_modeS_IWUSR)|| /* recipient can write? */
S_ISLNK(stbuf.st_mode)|| /* no symbolic links */
(S_ISDIR(stbuf.st_mode)?/* directories, yes, hardlinks */
!(stbuf.st_modeS_IXUSR):stbuf.st_nlink!=1)) /* no */
/*
* If another procmail is about to create the new
* mailbox, and has just made the link, st_nlink==2
*/
As You can see, this is not good idea to use procmail when anyone can made
a hardlink to my mailbox.
--
Pawe Jakub Dawidek
Network Administrator.
Am I Evil? Yes, I Am.
msg33416/pgp0.pgp
Description: PGP signature
Re: Hardlinks...
Pawe³ Jakub Dawidek wrote: Hey... Why I can made hardlink to file that I'm not owner? Simple example why I think that only owner should have permission to create hardlinks to his files. Among other things, so that you can use programs that use file locks based on link count. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Hardlinks...
Michael Smith wrote: You misunderstand the original poster's complaint. The issue is that a non-owner can cause the owner's file to remain alive even after the owner has deleted it. Hence the comment about later breakin. You could also use this technique to maliciously exhaust a user's quota, by linking to their temporary files. I'm not sure what the standards have to say about this, but I don't much like the current behaviour. I think that making the links in temporary directories should not be allowed, by dint of the t bit in the user of the directory in which the file is being created. I think the problem with someone else making a link to my file and keeping it around is an issue of access controls to the file itself, and not really a problem: e.g. if you want to avoid it, don't rely on obscurity, and don't permit exterior access to the files. Actually, people have complained about not having a flink(2) call to create a directory entry for an open file. I think if this were there, then the problem would be genuine; but without it, it's a matter of controlling access to the files. I wouldn't be opposed to a patch that prevented creation of links to files you don't own, if the 't' bit were set on the wource or destination directory, but which would permit the operation otherwise. I think a patch that disallowed it entirely would break /var/spool/lock based locking. 8-(. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Hardlinks...
In the last episode (Apr 08), Terry Lambert said: Michael Smith wrote: You misunderstand the original poster's complaint. The issue is that a non-owner can cause the owner's file to remain alive even after the owner has deleted it. Hence the comment about later breakin. You could also use this technique to maliciously exhaust a user's quota, by linking to their temporary files. I'm not sure what the standards have to say about this, but I don't much like the current behaviour. I think that making the links in temporary directories should not be allowed, by dint of the t bit in the user of the directory in which the file is being created. So the user creates /tmp/zzz/ , chmod 0's /tmp/zzz, and sticks his link in there. I think the problem with someone else making a link to my file and keeping it around is an issue of access controls to the file itself, and not really a problem: e.g. if you want to avoid it, don't rely on obscurity, and don't permit exterior access to the files. But the question is should execute permission on a directory imply link permission for all files in the directory? If so, we'll have to move master.passwd and spwd.db out of etc, then. Into /etc/shadow/ (chmod 0) maybe? If the user can cd into the directory the file is in, he can link it elsewhere. You don't even need read permission on the directory. This might be a bit paranoid, as a problem only exists if the user later is able to gain root to access the files he stashed away earlier. The most paranoid admin would have to make sure that no world-writable directories exist on the same partition as files he wants to keep secure. I think a patch that disallowed it entirely would break /var/spool/lock based locking. 8-(. But for UUCP locking, you're linking a tempfile that you just created to the true lock name. You are linking from a file you own, which would be allowed even under the strictest lockdown of link. I think it'd work fine. -- Dan Nelson [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Hardlinks...
Dan Nelson wrote: I think the problem with someone else making a link to my file and keeping it around is an issue of access controls to the file itself, and not really a problem: e.g. if you want to avoid it, don't rely on obscurity, and don't permit exterior access to the files. But the question is should execute permission on a directory imply link permission for all files in the directory? If you can copy it, you should be allowed to link it; if you can't, then you shouldn't. If so, we'll have to move master.passwd and spwd.db out of etc, then. Into /etc/shadow/ (chmod 0) maybe? If the user can cd into the directory the file is in, he can link it elsewhere. You don't even need read permission on the directory. The ability to link to files you don't have read access to is rather ridiculous. The patch that was proposed, though shot you in the head, even if you do have read access (e.g. as in a LCK..tty0 file). It's arguable that / and /usr themselves should be mounted read-only, and that /tmp should be elsewhere, though, so this could be portrayed as an administrative issue, not a kernel issue. I think a patch that disallowed it entirely would break /var/spool/lock based locking. 8-(. But for UUCP locking, you're linking a tempfile that you just created to the true lock name. You are linking from a file you own, which would be allowed even under the strictest lockdown of link. I think it'd work fine. Think lock override due to ``kill -0'' giving ESRCH instead of EPERM or success. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
