<feed xmlns='http://www.w3.org/2005/Atom'>
<title>src/sys/security/mac/mac_syscalls.c, branch releng/10.3</title>
<subtitle>FreeBSD source tree</subtitle>
<link rel='alternate' type='text/html' href='http://cgit.freebsd.org/src/'/>
<entry>
<title>Merge r263233 from HEAD to stable/10:</title>
<updated>2015-03-19T13:37:36+00:00</updated>
<author>
<name>Robert Watson</name>
<email>rwatson@FreeBSD.org</email>
</author>
<published>2015-03-19T13:37:36+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.freebsd.org/src/commit/?id=8c0b8b26921d2b7336f487bf71f7bf9e555e374e'/>
<id>8c0b8b26921d2b7336f487bf71f7bf9e555e374e</id>
<content type='text'>
  Update kernel inclusions of capability.h to use capsicum.h instead; some
  further refinement is required as some device drivers intended to be
  portable over FreeBSD versions rely on __FreeBSD_version to decide whether
  to include capability.h.

Sponsored by:	Google, Inc.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
  Update kernel inclusions of capability.h to use capsicum.h instead; some
  further refinement is required as some device drivers intended to be
  portable over FreeBSD versions rely on __FreeBSD_version to decide whether
  to include capability.h.

Sponsored by:	Google, Inc.
</pre>
</div>
</content>
</entry>
<entry>
<title>Change the cap_rights_t type from uint64_t to a structure that we can extend</title>
<updated>2013-09-05T00:09:56+00:00</updated>
<author>
<name>Pawel Jakub Dawidek</name>
<email>pjd@FreeBSD.org</email>
</author>
<published>2013-09-05T00:09:56+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.freebsd.org/src/commit/?id=7008be5bd7341259037f383434a72960413cfeb8'/>
<id>7008be5bd7341259037f383434a72960413cfeb8</id>
<content type='text'>
in the future in a backward compatible (API and ABI) way.

The cap_rights_t represents capability rights. We used to use one bit to
represent one right, but we are running out of spare bits. Currently the new
structure provides place for 114 rights (so 50 more than the previous
cap_rights_t), but it is possible to grow the structure to hold at least 285
rights, although we can make it even larger if 285 rights won't be enough.

The structure definition looks like this:

	struct cap_rights {
		uint64_t	cr_rights[CAP_RIGHTS_VERSION + 2];
	};

The initial CAP_RIGHTS_VERSION is 0.

The top two bits in the first element of the cr_rights[] array contain total
number of elements in the array - 2. This means if those two bits are equal to
0, we have 2 array elements.

The top two bits in all remaining array elements should be 0.
The next five bits in all array elements contain array index. Only one bit is
used and bit position in this five-bits range defines array index. This means
there can be at most five array elements in the future.

To define new right the CAPRIGHT() macro must be used. The macro takes two
arguments - an array index and a bit to set, eg.

	#define	CAP_PDKILL	CAPRIGHT(1, 0x0000000000000800ULL)

We still support aliases that combine few rights, but the rights have to belong
to the same array element, eg:

	#define	CAP_LOOKUP	CAPRIGHT(0, 0x0000000000000400ULL)
	#define	CAP_FCHMOD	CAPRIGHT(0, 0x0000000000002000ULL)

	#define	CAP_FCHMODAT	(CAP_FCHMOD | CAP_LOOKUP)

There is new API to manage the new cap_rights_t structure:

	cap_rights_t *cap_rights_init(cap_rights_t *rights, ...);
	void cap_rights_set(cap_rights_t *rights, ...);
	void cap_rights_clear(cap_rights_t *rights, ...);
	bool cap_rights_is_set(const cap_rights_t *rights, ...);

	bool cap_rights_is_valid(const cap_rights_t *rights);
	void cap_rights_merge(cap_rights_t *dst, const cap_rights_t *src);
	void cap_rights_remove(cap_rights_t *dst, const cap_rights_t *src);
	bool cap_rights_contains(const cap_rights_t *big, const cap_rights_t *little);

Capability rights to the cap_rights_init(), cap_rights_set(),
cap_rights_clear() and cap_rights_is_set() functions are provided by
separating them with commas, eg:

	cap_rights_t rights;

	cap_rights_init(&amp;rights, CAP_READ, CAP_WRITE, CAP_FSTAT);

There is no need to terminate the list of rights, as those functions are
actually macros that take care of the termination, eg:

	#define	cap_rights_set(rights, ...)				\
		__cap_rights_set((rights), __VA_ARGS__, 0ULL)
	void __cap_rights_set(cap_rights_t *rights, ...);

Thanks to using one bit as an array index we can assert in those functions that
there are no two rights belonging to different array elements provided
together. For example this is illegal and will be detected, because CAP_LOOKUP
belongs to element 0 and CAP_PDKILL to element 1:

	cap_rights_init(&amp;rights, CAP_LOOKUP | CAP_PDKILL);

Providing several rights that belongs to the same array's element this way is
correct, but is not advised. It should only be used for aliases definition.

This commit also breaks compatibility with some existing Capsicum system calls,
but I see no other way to do that. This should be fine as Capsicum is still
experimental and this change is not going to 9.x.

Sponsored by:	The FreeBSD Foundation
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
in the future in a backward compatible (API and ABI) way.

The cap_rights_t represents capability rights. We used to use one bit to
represent one right, but we are running out of spare bits. Currently the new
structure provides place for 114 rights (so 50 more than the previous
cap_rights_t), but it is possible to grow the structure to hold at least 285
rights, although we can make it even larger if 285 rights won't be enough.

The structure definition looks like this:

	struct cap_rights {
		uint64_t	cr_rights[CAP_RIGHTS_VERSION + 2];
	};

The initial CAP_RIGHTS_VERSION is 0.

The top two bits in the first element of the cr_rights[] array contain total
number of elements in the array - 2. This means if those two bits are equal to
0, we have 2 array elements.

The top two bits in all remaining array elements should be 0.
The next five bits in all array elements contain array index. Only one bit is
used and bit position in this five-bits range defines array index. This means
there can be at most five array elements in the future.

To define new right the CAPRIGHT() macro must be used. The macro takes two
arguments - an array index and a bit to set, eg.

	#define	CAP_PDKILL	CAPRIGHT(1, 0x0000000000000800ULL)

We still support aliases that combine few rights, but the rights have to belong
to the same array element, eg:

	#define	CAP_LOOKUP	CAPRIGHT(0, 0x0000000000000400ULL)
	#define	CAP_FCHMOD	CAPRIGHT(0, 0x0000000000002000ULL)

	#define	CAP_FCHMODAT	(CAP_FCHMOD | CAP_LOOKUP)

There is new API to manage the new cap_rights_t structure:

	cap_rights_t *cap_rights_init(cap_rights_t *rights, ...);
	void cap_rights_set(cap_rights_t *rights, ...);
	void cap_rights_clear(cap_rights_t *rights, ...);
	bool cap_rights_is_set(const cap_rights_t *rights, ...);

	bool cap_rights_is_valid(const cap_rights_t *rights);
	void cap_rights_merge(cap_rights_t *dst, const cap_rights_t *src);
	void cap_rights_remove(cap_rights_t *dst, const cap_rights_t *src);
	bool cap_rights_contains(const cap_rights_t *big, const cap_rights_t *little);

Capability rights to the cap_rights_init(), cap_rights_set(),
cap_rights_clear() and cap_rights_is_set() functions are provided by
separating them with commas, eg:

	cap_rights_t rights;

	cap_rights_init(&amp;rights, CAP_READ, CAP_WRITE, CAP_FSTAT);

There is no need to terminate the list of rights, as those functions are
actually macros that take care of the termination, eg:

	#define	cap_rights_set(rights, ...)				\
		__cap_rights_set((rights), __VA_ARGS__, 0ULL)
	void __cap_rights_set(cap_rights_t *rights, ...);

Thanks to using one bit as an array index we can assert in those functions that
there are no two rights belonging to different array elements provided
together. For example this is illegal and will be detected, because CAP_LOOKUP
belongs to element 0 and CAP_PDKILL to element 1:

	cap_rights_init(&amp;rights, CAP_LOOKUP | CAP_PDKILL);

Providing several rights that belongs to the same array's element this way is
correct, but is not advised. It should only be used for aliases definition.

This commit also breaks compatibility with some existing Capsicum system calls,
but I see no other way to do that. This should be fine as Capsicum is still
experimental and this change is not going to 9.x.

Sponsored by:	The FreeBSD Foundation
</pre>
</div>
</content>
</entry>
<entry>
<title>Remove the support for using non-mpsafe filesystem modules.</title>
<updated>2012-10-22T17:50:54+00:00</updated>
<author>
<name>Konstantin Belousov</name>
<email>kib@FreeBSD.org</email>
</author>
<published>2012-10-22T17:50:54+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.freebsd.org/src/commit/?id=5050aa86cff105784877fb886a7b1d25bca5813b'/>
<id>5050aa86cff105784877fb886a7b1d25bca5813b</id>
<content type='text'>
In particular, do not lock Giant conditionally when calling into the
filesystem module, remove the VFS_LOCK_GIANT() and related
macros. Stop handling buffers belonging to non-mpsafe filesystems.

The VFS_VERSION is bumped to indicate the interface change which does
not result in the interface signatures changes.

Conducted and reviewed by:	attilio
Tested by:	pho
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
In particular, do not lock Giant conditionally when calling into the
filesystem module, remove the VFS_LOCK_GIANT() and related
macros. Stop handling buffers belonging to non-mpsafe filesystems.

The VFS_VERSION is bumped to indicate the interface change which does
not result in the interface signatures changes.

Conducted and reviewed by:	attilio
Tested by:	pho
</pre>
</div>
</content>
</entry>
<entry>
<title>When allocation of labels on files is implicitly disabled due to MAC</title>
<updated>2012-04-08T11:01:49+00:00</updated>
<author>
<name>Robert Watson</name>
<email>rwatson@FreeBSD.org</email>
</author>
<published>2012-04-08T11:01:49+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.freebsd.org/src/commit/?id=b4ef8be22825539e023b5311c60b627fd6c00d4d'/>
<id>b4ef8be22825539e023b5311c60b627fd6c00d4d</id>
<content type='text'>
policy configuration, avoid leaking resources following failed calls
to get and set MAC labels by file descriptor.

Reported by:	Mateusz Guzik &lt;mjguzik at gmail.com&gt; + clang scan-build
MFC after:	3 days
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
policy configuration, avoid leaking resources following failed calls
to get and set MAC labels by file descriptor.

Reported by:	Mateusz Guzik &lt;mjguzik at gmail.com&gt; + clang scan-build
MFC after:	3 days
</pre>
</div>
</content>
</entry>
<entry>
<title>In order to maximize the re-usability of kernel code in user space this</title>
<updated>2011-09-16T13:58:51+00:00</updated>
<author>
<name>Kip Macy</name>
<email>kmacy@FreeBSD.org</email>
</author>
<published>2011-09-16T13:58:51+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.freebsd.org/src/commit/?id=8451d0dd78c0a9c0383485b18aba9f081a9db8bb'/>
<id>8451d0dd78c0a9c0383485b18aba9f081a9db8bb</id>
<content type='text'>
patch modifies makesyscalls.sh to prefix all of the non-compatibility
calls (e.g. not linux_, freebsd32_) with sys_ and updates the kernel
entry points and all places in the code that use them. It also
fixes an additional name space collision between the kernel function
psignal and the libc function of the same name by renaming the kernel
psignal kern_psignal(). By introducing this change now we will ease future
MFCs that change syscalls.

Reviewed by:	rwatson
Approved by:	re (bz)
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
patch modifies makesyscalls.sh to prefix all of the non-compatibility
calls (e.g. not linux_, freebsd32_) with sys_ and updates the kernel
entry points and all places in the code that use them. It also
fixes an additional name space collision between the kernel function
psignal and the libc function of the same name by renaming the kernel
psignal kern_psignal(). By introducing this change now we will ease future
MFCs that change syscalls.

Reviewed by:	rwatson
Approved by:	re (bz)
</pre>
</div>
</content>
</entry>
<entry>
<title>Second-to-last commit implementing Capsicum capabilities in the FreeBSD</title>
<updated>2011-08-11T12:30:23+00:00</updated>
<author>
<name>Robert Watson</name>
<email>rwatson@FreeBSD.org</email>
</author>
<published>2011-08-11T12:30:23+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.freebsd.org/src/commit/?id=a9d2f8d84f69e98100b5746816b35666bcf992ac'/>
<id>a9d2f8d84f69e98100b5746816b35666bcf992ac</id>
<content type='text'>
kernel for FreeBSD 9.0:

Add a new capability mask argument to fget(9) and friends, allowing system
call code to declare what capabilities are required when an integer file
descriptor is converted into an in-kernel struct file *.  With options
CAPABILITIES compiled into the kernel, this enforces capability
protection; without, this change is effectively a no-op.

Some cases require special handling, such as mmap(2), which must preserve
information about the maximum rights at the time of mapping in the memory
map so that they can later be enforced in mprotect(2) -- this is done by
narrowing the rights in the existing max_protection field used for similar
purposes with file permissions.

In namei(9), we assert that the code is not reached from within capability
mode, as we're not yet ready to enforce namespace capabilities there.
This will follow in a later commit.

Update two capability names: CAP_EVENT and CAP_KEVENT become
CAP_POST_KEVENT and CAP_POLL_KEVENT to more accurately indicate what they
represent.

Approved by:	re (bz)
Submitted by:	jonathan
Sponsored by:	Google Inc
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
kernel for FreeBSD 9.0:

Add a new capability mask argument to fget(9) and friends, allowing system
call code to declare what capabilities are required when an integer file
descriptor is converted into an in-kernel struct file *.  With options
CAPABILITIES compiled into the kernel, this enforces capability
protection; without, this change is effectively a no-op.

Some cases require special handling, such as mmap(2), which must preserve
information about the maximum rights at the time of mapping in the memory
map so that they can later be enforced in mprotect(2) -- this is done by
narrowing the rights in the existing max_protection field used for similar
purposes with file permissions.

In namei(9), we assert that the code is not reached from within capability
mode, as we're not yet ready to enforce namespace capabilities there.
This will follow in a later commit.

Update two capability names: CAP_EVENT and CAP_KEVENT become
CAP_POST_KEVENT and CAP_POLL_KEVENT to more accurately indicate what they
represent.

Approved by:	re (bz)
Submitted by:	jonathan
Sponsored by:	Google Inc
</pre>
</div>
</content>
</entry>
<entry>
<title>- Add a FEATURE for capsicum (security_capabilities).</title>
<updated>2011-03-04T09:03:54+00:00</updated>
<author>
<name>Alexander Leidinger</name>
<email>netchild@FreeBSD.org</email>
</author>
<published>2011-03-04T09:03:54+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.freebsd.org/src/commit/?id=d783bbd2d2510ea60941e6032b303095f43c2fbd'/>
<id>d783bbd2d2510ea60941e6032b303095f43c2fbd</id>
<content type='text'>
- Rename mac FEATURE to security_mac.

Discussed with:	rwatson
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
- Rename mac FEATURE to security_mac.

Discussed with:	rwatson
</pre>
</div>
</content>
</entry>
<entry>
<title>Add some FEATURE macros for various features (AUDIT/CAM/IPC/KTR/MAC/NFS/NTP/</title>
<updated>2011-02-25T10:11:01+00:00</updated>
<author>
<name>Alexander Leidinger</name>
<email>netchild@FreeBSD.org</email>
</author>
<published>2011-02-25T10:11:01+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.freebsd.org/src/commit/?id=de5b19526b7350b9c608ae4bf0bd80b91e51a5df'/>
<id>de5b19526b7350b9c608ae4bf0bd80b91e51a5df</id>
<content type='text'>
PMC/SYSV/...).

No FreeBSD version bump, the userland application to query the features will
be committed last and can serve as an indication of the availablility if
needed.

Sponsored by:   Google Summer of Code 2010
Submitted by:   kibab
Reviewed by:    arch@ (parts by rwatson, trasz, jhb)
X-MFC after:    to be determined in last commit with code from this project
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
PMC/SYSV/...).

No FreeBSD version bump, the userland application to query the features will
be committed last and can serve as an indication of the availablility if
needed.

Sponsored by:   Google Summer of Code 2010
Submitted by:   kibab
Reviewed by:    arch@ (parts by rwatson, trasz, jhb)
X-MFC after:    to be determined in last commit with code from this project
</pre>
</div>
</content>
</entry>
<entry>
<title>Rework MAC Framework synchronization in a number of ways in order to</title>
<updated>2009-03-14T16:06:06+00:00</updated>
<author>
<name>Robert Watson</name>
<email>rwatson@FreeBSD.org</email>
</author>
<published>2009-03-14T16:06:06+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.freebsd.org/src/commit/?id=4020272933cbe552f932d9642419f8becee04bd5'/>
<id>4020272933cbe552f932d9642419f8becee04bd5</id>
<content type='text'>
improve performance:

- Eliminate custom reference count and condition variable to monitor
  threads entering the framework, as this had both significant overhead
  and behaved badly in the face of contention.

- Replace reference count with two locks: an rwlock and an sx lock,
  which will be read-acquired by threads entering the framework
  depending on whether a give policy entry point is permitted to sleep
  or not.

- Replace previous mutex locking of the reference count for exclusive
  access with write acquiring of both the policy list sx and rw locks,
  which occurs only when policies are attached or detached.

- Do a lockless read of the dynamic policy list head before acquiring
  any locks in order to reduce overhead when no dynamic policies are
  loaded; this a race we can afford to lose.

- For every policy entry point invocation, decide whether sleeping is
  permitted, and if not, use a _NOSLEEP() variant of the composition
  macros, which will use the rwlock instead of the sxlock.  In some
  cases, we decide which to use based on allocation flags passed to the
  MAC Framework entry point.

As with the move to rwlocks/rmlocks in pfil, this may trigger witness
warnings, but these should (generally) be false positives as all
acquisition of the locks is for read with two very narrow exceptions
for policy load/unload, and those code blocks should never acquire
other locks.

Sponsored by:	Google, Inc.
Obtained from:	TrustedBSD Project
Discussed with:	csjp (idea, not specific patch)
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
improve performance:

- Eliminate custom reference count and condition variable to monitor
  threads entering the framework, as this had both significant overhead
  and behaved badly in the face of contention.

- Replace reference count with two locks: an rwlock and an sx lock,
  which will be read-acquired by threads entering the framework
  depending on whether a give policy entry point is permitted to sleep
  or not.

- Replace previous mutex locking of the reference count for exclusive
  access with write acquiring of both the policy list sx and rw locks,
  which occurs only when policies are attached or detached.

- Do a lockless read of the dynamic policy list head before acquiring
  any locks in order to reduce overhead when no dynamic policies are
  loaded; this a race we can afford to lose.

- For every policy entry point invocation, decide whether sleeping is
  permitted, and if not, use a _NOSLEEP() variant of the composition
  macros, which will use the rwlock instead of the sxlock.  In some
  cases, we decide which to use based on allocation flags passed to the
  MAC Framework entry point.

As with the move to rwlocks/rmlocks in pfil, this may trigger witness
warnings, but these should (generally) be false positives as all
acquisition of the locks is for read with two very narrow exceptions
for policy load/unload, and those code blocks should never acquire
other locks.

Sponsored by:	Google, Inc.
Obtained from:	TrustedBSD Project
Discussed with:	csjp (idea, not specific patch)
</pre>
</div>
</content>
</entry>
<entry>
<title>Rename mac_cred_mmapped_drop_perms(), which revokes access to virtual</title>
<updated>2008-10-28T12:49:07+00:00</updated>
<author>
<name>Robert Watson</name>
<email>rwatson@FreeBSD.org</email>
</author>
<published>2008-10-28T12:49:07+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.freebsd.org/src/commit/?id=9215889d21ffb366dda6fcbd62483657769367f2'/>
<id>9215889d21ffb366dda6fcbd62483657769367f2</id>
<content type='text'>
memory mappings when the MAC label on a process changes, to
mac_proc_vm_revoke(),

It now also acquires its own credential reference directly from the
affected process rather than accepting one passed by the the caller,
simplifying the API and consumer code.

Obtained from:	TrustedBSD Project
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
memory mappings when the MAC label on a process changes, to
mac_proc_vm_revoke(),

It now also acquires its own credential reference directly from the
affected process rather than accepting one passed by the the caller,
simplifying the API and consumer code.

Obtained from:	TrustedBSD Project
</pre>
</div>
</content>
</entry>
</feed>
