| Summary: | bsd_seeotheruids root user exempt from policy | ||
|---|---|---|---|
| Product: | Documentation | Reporter: | g <glaive> |
| Component: | Books & Articles | Assignee: | Robert Watson <rwatson> |
| Status: | Closed FIXED | ||
| Severity: | Affects Only Me | ||
| Priority: | Normal | ||
| Version: | Latest | ||
| Hardware: | Any | ||
| OS: | Any | ||
|
Description
g
2005-08-01 19:10:13 UTC
Responsible Changed From-To: freebsd-bugs->freebsd-doc This sounds like a problem with the Handbook. On 1 Aug 2005, at 21:27, Mark Linimon wrote: > Synopsis: bsd_seeotheruids root user exempt from policy > > Responsible-Changed-From-To: freebsd-bugs->freebsd-doc > Responsible-Changed-By: linimon > Responsible-Changed-When: Mon Aug 1 21:27:15 GMT 2005 > Responsible-Changed-Why: > This sounds like a problem with the Handbook. More information is required. Simply loading the kernel module is not enough; the sysctl security.mac.seeotheruids.enabled must be set to 1 for the policy to be active. Could the submitter please post the output of "sysctl -a | grep security.mac" on the affected system? Ceri -- Only two things are infinite, the universe and human stupidity, and I'm not sure about the former. -- Einstein (attrib.) State Changed From-To: open->feedback Feedback has been requested by Ceri. Set the state of the problem report to ``feedback'' to note we're expecting more information. On Mon, Aug 01, 2005 at 11:11:37PM +0100, Ceri Davies wrote:
> Could the submitter please post the output of "sysctl -a | grep
> security.mac" on the affected system?
sagan# sysctl -a | grep security.mac
security.mac.max_slots: 4
security.mac.enforce_network: 1
security.mac.enforce_pipe: 1
security.mac.enforce_posix_sem: 1
security.mac.enforce_process: 1
security.mac.enforce_vm: 1
security.mac.mmap_revocation: 1
security.mac.mmap_revocation_via_cow: 0
security.mac.enforce_suid: 1
security.mac.enforce_socket: 1
security.mac.enforce_kld: 1
security.mac.enforce_system: 1
security.mac.enforce_sysv_msg: 1
security.mac.enforce_sysv_sem: 1
security.mac.enforce_sysv_shm: 1
security.mac.enforce_fs: 1
security.mac.seeotheruids.specificgid: 0
security.mac.seeotheruids.specificgid_enabled: 0
security.mac.seeotheruids.primarygroup_enabled: 0
security.mac.seeotheruids.enabled: 1
sagan# whoami
root
sagan# ps aux | grep -v root
USER PID %CPU %MEM VSZ RSS TT STAT STARTED TIME COMMAND
smmsp 23960 0.0 0.3 3296 2692 ?? Is 8:31PM 0:00.00 sendmail: Queue
_dhcp 41957 0.0 0.1 1384 1068 ?? Is 8:32PM 0:00.00 dhclient: bge0 (
user0 52449 0.0 0.3 6076 3116 ?? S 8:40PM 0:00.01 sshd: user0@tty
user0 33386 0.0 0.2 2532 2040 v0 I 8:31PM 0:00.06 -zsh (zsh)
user0 52459 0.0 0.2 2512 2256 p0 Is 8:40PM 0:00.02 -zsh (zsh)
On Wed, 3 Aug 2005 01:50:15 GMT g@vaned.net wrote: > The following reply was made to PR docs/84453; it has been noted by > GNATS. > > From: g@vaned.net > To: Ceri Davies <ceri@submonkey.net> > Cc: freebsd-gnats-submit@freebsd.org > Subject: Re: docs/84453: bsd_seeotheruids root user exempt from policy > Date: Tue, 2 Aug 2005 20:45:02 -0500 > > On Mon, Aug 01, 2005 at 11:11:37PM +0100, Ceri Davies wrote: > > Could the submitter please post the output of "sysctl -a | grep > > security.mac" on the affected system? > > sagan# sysctl -a | grep security.mac > security.mac.max_slots: 4 [SNIP] > security.mac.seeotheruids.enabled: 1 > sagan# whoami > root [SNIP] There is not a problem with the user or user's configuration, there is not a problem with the handbook text, the software is incorrect here. The root user, or any user in the wheel group seems exempt from the security checks here. Robert Watson and I have discussed this, but have not implemented a fix. This PR can be assigned to either myself or rwatson. Perhaps to me so I can oversee it's closing. Otherwise, just close it. Thanks! -- Tom Rhodes Responsible Changed From-To: freebsd-doc->rwatson Grab ownership of this PR. This appears to be a case of out-of-sync documentation: mac_seeotheruids was changed to exempt the root user in change mac_seeotheruids.c:1.7, associated with PR 72238, which observed that while restricting the root user is technically feasible, it doesn't match common administrative models where restricting inter-user interactions is desirable. I.e., the root user now remains privileged with respect to this security model. State Changed From-To: feedback->closed doc/en_US.ISO8859-1/books/handbook/mac/chapter.sgml:1.45 removes the now stale comment. |