Hi. I've no response from so@ in this topic, probably because leak of time, so I'll try here. Here is a patch that I'm planing to commit: http://people.freebsd.org/~pjd/patches/restricted_hardlinks.patch It adds two new sysctls: security.bsd.hardlink_check_uid security.bsd.hardlink_check_gid If sysctl security.bsd.hardlink_check_uid is set to 1, unprivileged users are not permitted to create hard links to files not owned by them. If sysctl security.bsd.hardlink_check_gid is set to 1, unprivileged users are not permitted to create hard links to files if they are not member of file's group. For now user is able to create hardlinks to any files. -- Pawel Jakub Dawidek http://www.FreeBSD.org pjd@FreeBSD.org http://garage.freebsd.pl FreeBSD committer Am I Evil? Yes, I Am! -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-security/attachments/20040308/46973553/attachment.bin
On Mon, Mar 08, 2004 at 09:25:55PM +1100, Tim Robbins wrote: +> > It adds two new sysctls: +> > +> > security.bsd.hardlink_check_uid +> > security.bsd.hardlink_check_gid +> > +> > If sysctl security.bsd.hardlink_check_uid is set to 1, unprivileged users +> > are not permitted to create hard links to files not owned by them. +> > If sysctl security.bsd.hardlink_check_gid is set to 1, unprivileged users +> > are not permitted to create hard links to files if they are not member +> > of file's group. +> > +> > For now user is able to create hardlinks to any files. +> +> It might be more consistent with other UNIX access checks (e.g. vaccess()) +> if having the same uid as the file was sufficient to link to it, +> without having to be a group member. I can't convince myself either way +> on this, but it's worth thinking about. So you need to set security.bsd.hardlink_check_uid and don't touch security.bsd.hardlink_check_gid. +> Also be aware that as a side effect of this patch, old applications that use +> the unlink()/link()/unlink() sequence instead of the rename() system call +> may not be able to rename files they don't own. Default values for those sysctls is 0, so system behaviour will change only on administrator request. -- Pawel Jakub Dawidek http://www.FreeBSD.org pjd@FreeBSD.org http://garage.freebsd.pl FreeBSD committer Am I Evil? Yes, I Am! -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-security/attachments/20040308/fe9e4c72/attachment.bin
On Mon, Mar 08, 2004 at 10:10:38PM +0100, Georg-W. Koltermann wrote: +> When you restrict links, do you want to restrict copying as well? +> +> Seems somewhat paranoid to me. You already need write permission on the +> directory where you create the link, and permissions are checked against +> the inode on open(2) anyway. This is because this gives an attacker some possibilities. For example he is able to create hard link to some set-uid binary. After some time, a security-related bug will be found in this application, administrator will change it with good version, but old, vulnerable version will be still in system. Administrator have to be really careful when fixing such problems and check number of hard links or just remove such program using 'rm -P'. -- Pawel Jakub Dawidek http://www.FreeBSD.org pjd@FreeBSD.org http://garage.freebsd.pl FreeBSD committer Am I Evil? Yes, I Am! -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-security/attachments/20040308/0e99c1b0/attachment.bin
On Mon, Mar 08, 2004 at 10:36:42AM +0100, Pawel Jakub Dawidek wrote:> Hi. > > I've no response from so@ in this topic, probably because leak of time, > so I'll try here. > > Here is a patch that I'm planing to commit: > > http://people.freebsd.org/~pjd/patches/restricted_hardlinks.patch > > It adds two new sysctls: > > security.bsd.hardlink_check_uid > security.bsd.hardlink_check_gid > > If sysctl security.bsd.hardlink_check_uid is set to 1, unprivileged users > are not permitted to create hard links to files not owned by them. > If sysctl security.bsd.hardlink_check_gid is set to 1, unprivileged users > are not permitted to create hard links to files if they are not member > of file's group. > > For now user is able to create hardlinks to any files.It might be more consistent with other UNIX access checks (e.g. vaccess()) if having the same uid as the file was sufficient to link to it, without having to be a group member. I can't convince myself either way on this, but it's worth thinking about. Also be aware that as a side effect of this patch, old applications that use the unlink()/link()/unlink() sequence instead of the rename() system call may not be able to rename files they don't own. Tim
When you restrict links, do you want to restrict copying as well? Seems somewhat paranoid to me. You already need write permission on the directory where you create the link, and permissions are checked against the inode on open(2) anyway. My $0.0002. -- Regards, Georg. Am Mo, den 08.03.2004 schrieb Pawel Jakub Dawidek um 10:36:> Hi. > > I've no response from so@ in this topic, probably because leak of time, > so I'll try here. > > Here is a patch that I'm planing to commit: > > http://people.freebsd.org/~pjd/patches/restricted_hardlinks.patch > > It adds two new sysctls: > > security.bsd.hardlink_check_uid > security.bsd.hardlink_check_gid > > If sysctl security.bsd.hardlink_check_uid is set to 1, unprivileged users > are not permitted to create hard links to files not owned by them. > If sysctl security.bsd.hardlink_check_gid is set to 1, unprivileged users > are not permitted to create hard links to files if they are not member > of file's group. > > For now user is able to create hardlinks to any files.