headers
Bruce Evans | 1 Jan 2007 11:06
Picon

Re: default value of security.bsd.hardlink_check_[ug]id

On Sun, 31 Dec 2006, Robert Watson wrote:

> I'm not entirely happy with the current implementation, FWIW.  I'd like 
> can_hardlink to be implemented in the per file system code, possibly by 
> invoking a common routine of this sort, avoiding the extra call to 
> VOP_GETATTR(), and allowing file systems not implementing ownership in 
> traditional ways (msdosfs, etc) to do whatever makes sense in their context. 
> On the whole, these sorts of decisions are made in each file system, often 
> using common code (perhaps centralized), and not at the VFS layer.

I think it also has wrong semantics.  It denies privilege based on
non-ownership, while everything that uses vaccess() grants privilege
based on ownership.  This gives the surprising behaviour that if
hardlink_check_gid = 1, the owner of a file can do anything to the
file except link to it in cases where the group of the file isn't in
the caller's group list (and no immutable but is set).

Bruce
_______________________________________________
freebsd-arch <at> freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe <at> freebsd.org"
Permalink | Reply | 1 comment |
headers
Robert Watson | 1 Jan 2007 11:41
Picon
Favicon

Re: default value of security.bsd.hardlink_check_[ug]id


On Mon, 1 Jan 2007, Bruce Evans wrote:

> On Sun, 31 Dec 2006, Robert Watson wrote:
>
>> I'm not entirely happy with the current implementation, FWIW.  I'd like 
>> can_hardlink to be implemented in the per file system code, possibly by 
>> invoking a common routine of this sort, avoiding the extra call to 
>> VOP_GETATTR(), and allowing file systems not implementing ownership in 
>> traditional ways (msdosfs, etc) to do whatever makes sense in their 
>> context. On the whole, these sorts of decisions are made in each file 
>> system, often using common code (perhaps centralized), and not at the VFS 
>> layer.
>
> I think it also has wrong semantics.  It denies privilege based on 
> non-ownership, while everything that uses vaccess() grants privilege based 
> on ownership.  This gives the surprising behaviour that if 
> hardlink_check_gid = 1, the owner of a file can do anything to the file 
> except link to it in cases where the group of the file isn't in the caller's 
> group list (and no immutable but is set).

Yes, I think you're right.  Per our earlier thread on the structure of 
privilege checks on arch <at> , security checks generally shold look something like 
this:

error = dac_check(cred, object);
if (error) {
 	error = priv_check(cred, privilege);
 	if (error)
 		return (error);
(Continue reading)

Permalink | Reply | 0 comments |
headers
M. Warner Losh | 1 Jan 2007 19:38

usb modems and com devices into GENERIC

I'd like to place the following in GENERIC.  We're getting more and
more questions about these devices that we wouldn't be getting if we
had them compiled in by default.  The really imporant ones are marked
with a '*' below

device		ucom		# *
device		umodem		# *
device		umct
device		uark
device		ubsa
device		ubser
device		uftdi		# *
device		uplcom		# *
device		uvisor
device		uvscom

the cost isn's so much, and we can filter them out from the
installation kernel if size is an issue.

Comments?

Warner
_______________________________________________
freebsd-arch <at> freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe <at> freebsd.org"
Permalink | Reply | 6 comments |
headers
Rink Springer | 1 Jan 2007 19:41
Picon
Favicon

Re: usb modems and com devices into GENERIC

Hi Warner,

On Mon, Jan 01, 2007 at 11:38:01AM -0700, M. Warner Losh wrote:
> I'd like to place the following in GENERIC.  We're getting more and
> more questions about these devices that we wouldn't be getting if we
> had them compiled in by default.  The really imporant ones are marked
> with a '*' below
> 
> device		ucom		# *
> device		umodem		# *
> device		umct
> device		uark
> device		ubsa
> device		ubser
> device		uftdi		# *
> device		uplcom		# *
> device		uvisor
> device		uvscom
> 
> the cost isn's so much, and we can filter them out from the
> installation kernel if size is an issue.
> 
> Comments?
> 
> Warner

Sounds good to me. I usually kldload(8) some of this for my uplcom(4),
but it would not hurt having this in GENERIC.

I'm all in favor.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Colin Percival | 2 Jan 2007 05:54
Picon
Favicon

Re: default value of security.bsd.hardlink_check_[ug]id

Ceri Davies wrote:
> On Sat, Dec 30, 2006 at 09:08:42PM -0800, Colin Percival wrote:
>> I'd like to make security.bsd.hardlink_check_[ug]id default to 1, starting
>> with FreeBSD 7.x.  This would make it impossible for a user to create a hard
>> link to a file which he does not own.
> 
>  a) you have provided no rationale;

Allowing users to create hard links to files which they do not own creates
problems:
1. If disk quotas are enabled, a user can waste another user's disk quota by
making it impossible for said other user to delete files.
2. It becomes difficult to apply security fixes for issues involving setuid
binaries, since a local attacker could create hard links to all the setuid
binaries (or at least those on filesystems where he can write somewhere) and
wait for a security issue to be found.

I honestly can't see why it was ever possible for users to create hard links
to files which they don't own; hopefully someone can provide the historical
background and tell me if the original reasons (whatever they were) still
apply.

If it isn't possible to outlaw such hard linking entirely, I'd like to make
it impossible by default for
(a) a user to create a hard link to a setuid file which they do not own, and
(b) a user to create a hard link to a setgid file if they are not in the right
group,
since these are the important cases for security.

Colin Percival
(Continue reading)

Permalink | Reply | 3 comments |
headers
Ceri Davies | 2 Jan 2007 12:05
Gravatar

Re: default value of security.bsd.hardlink_check_[ug]id

On Mon, Jan 01, 2007 at 08:54:20PM -0800, Colin Percival wrote:
> Ceri Davies wrote:
> > On Sat, Dec 30, 2006 at 09:08:42PM -0800, Colin Percival wrote:
> >> I'd like to make security.bsd.hardlink_check_[ug]id default to 1, starting
> >> with FreeBSD 7.x.  This would make it impossible for a user to create a hard
> >> link to a file which he does not own.
> > 
> >  a) you have provided no rationale;
> 
> Allowing users to create hard links to files which they do not own creates
> problems:
> 1. If disk quotas are enabled, a user can waste another user's disk quota by
> making it impossible for said other user to delete files.
> 2. It becomes difficult to apply security fixes for issues involving setuid
> binaries, since a local attacker could create hard links to all the setuid
> binaries (or at least those on filesystems where he can write somewhere) and
> wait for a security issue to be found.
> 
> I honestly can't see why it was ever possible for users to create hard links
> to files which they don't own; hopefully someone can provide the historical
> background and tell me if the original reasons (whatever they were) still
> apply.

Notwithstanding the lack of documentation of the sysctls, I'm happy;
thanks for the follow up.

I've changed my Solaris 10 "crash" box to remove this ability from the
basic set [1]; I'll report if anything seems to go awry with it.

Ceri
(Continue reading)

Permalink | Reply | 0 comments |
headers
Robert Watson | 3 Jan 2007 00:07
Picon
Favicon

Re: default value of security.bsd.hardlink_check_[ug]id


On Mon, 1 Jan 2007, Colin Percival wrote:

> Ceri Davies wrote:
>> On Sat, Dec 30, 2006 at 09:08:42PM -0800, Colin Percival wrote:
>>> I'd like to make security.bsd.hardlink_check_[ug]id default to 1, starting
>>> with FreeBSD 7.x.  This would make it impossible for a user to create a hard
>>> link to a file which he does not own.
>>
>>  a) you have provided no rationale;
>
> Allowing users to create hard links to files which they do not own creates
> problems:
> 1. If disk quotas are enabled, a user can waste another user's disk quota by
> making it impossible for said other user to delete files.
> 2. It becomes difficult to apply security fixes for issues involving setuid
> binaries, since a local attacker could create hard links to all the setuid
> binaries (or at least those on filesystems where he can write somewhere) and
> wait for a security issue to be found.

I find the second argument here most compelling, and use it as an example 
frequently when complaining about hard links.  Hard links also one of the 
elements that makes it difficult to usefully generate names for file system 
objects, due to their introducing ambiguity.

> I honestly can't see why it was ever possible for users to create hard links 
> to files which they don't own; hopefully someone can provide the historical 
> background and tell me if the original reasons (whatever they were) still 
> apply.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Ulrich Spoerlein | 3 Jan 2007 21:58
Picon

Re: usb modems and com devices into GENERIC

M. Warner Losh wrote:
> I'd like to place the following in GENERIC.  We're getting more and
> more questions about these devices that we wouldn't be getting if we
> had them compiled in by default.  The really imporant ones are marked
> with a '*' below
> 
> device		ucom		# *
> device		umodem		# *
> device		umct
> device		uark
> device		ubsa
> device		ubser
> device		uftdi		# *
> device		uplcom		# *
> device		uvisor
> device		uvscom
> 
> the cost isn's so much, and we can filter them out from the
> installation kernel if size is an issue.
> 
> Comments?

Hi Warner,

why not do it the other way round? Keep them out of GENERIC, but have
loader(8) load some of the most used modules (snd_driver!) per default.

That way, people can easily disable these (without needing to
recompile).
(Continue reading)

Permalink | Reply | 4 comments |
headers
M. Warner Losh | 4 Jan 2007 04:34

Re: usb modems and com devices into GENERIC

In message: <20070103205841.GB85200 <at> roadrunner.q.local>
            Ulrich Spoerlein <uspoerlein <at> gmail.com> writes:
: M. Warner Losh wrote:
: > I'd like to place the following in GENERIC.  We're getting more and
: > more questions about these devices that we wouldn't be getting if we
: > had them compiled in by default.  The really imporant ones are marked
: > with a '*' below
: > 
: > device		ucom		# *
: > device		umodem		# *
: > device		umct
: > device		uark
: > device		ubsa
: > device		ubser
: > device		uftdi		# *
: > device		uplcom		# *
: > device		uvisor
: > device		uvscom
: > 
: > the cost isn's so much, and we can filter them out from the
: > installation kernel if size is an issue.
: > 
: > Comments?
: 
: Hi Warner,
: 
: why not do it the other way round? Keep them out of GENERIC, but have
: loader(8) load some of the most used modules (snd_driver!) per default.
: 
: That way, people can easily disable these (without needing to
(Continue reading)

Permalink | Reply | 1 comment |
headers
Milan Obuch | 4 Jan 2007 07:57
Picon

Re: usb modems and com devices into GENERIC

On Thursday 04 January 2007 04:34, M. Warner Losh wrote:
> In message: <20070103205841.GB85200 <at> roadrunner.q.local>
>
>             Ulrich Spoerlein <uspoerlein <at> gmail.com> writes:
> : M. Warner Losh wrote:
> : > I'd like to place the following in GENERIC.  We're getting more and
> : > more questions about these devices that we wouldn't be getting if we
> : > had them compiled in by default.  The really imporant ones are marked
> : > with a '*' below
> : >
> : > device		ucom		# *
> : > device		umodem		# *
> : > device		umct
> : > device		uark
> : > device		ubsa
> : > device		ubser
> : > device		uftdi		# *
> : > device		uplcom		# *
> : > device		uvisor
> : > device		uvscom
> : >
> : > the cost isn's so much, and we can filter them out from the
> : > installation kernel if size is an issue.
> : >
> : > Comments?
> :
> : Hi Warner,
> :
> : why not do it the other way round? Keep them out of GENERIC, but have
> : loader(8) load some of the most used modules (snd_driver!) per default.
(Continue reading)

Permalink | Reply | 0 comments |

Gmane