Security Enhanced Linux
What's New
Frequently Asked Questions
Background
Documents
License
Download
Participating
Mail List
Archives
Remaining Work
Contributors
Related Work
Press Releases
Information Assurance Research
NIARL In-house Research Areas
Mathematical Sciences Program
Sabbaticals
Computer & Information Sciences Research
Technology Transfer
Advanced Computing
Advanced Mathematics
Communications & Networking
Information Processing
Microelectronics
Other Technologies
Technology Fact Sheets
Publications
Related Links
|
SELinux Mailing List
subject: Proposed patch for libselinux Date: Thu, 21 Oct 2004 17:35:54 -0400
chcon will always set the permanent flag. restorecon and setfiles will ignore permanent files, unless the -F flag is passed which will cause them to modify the context. Examples of where a sysadmin would want to use this is for html pages. What do you think?
Downsides:
Dan
-- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with the words "unsubscribe selinux" without quotes as the message.From: Stephen Smalley <sds_at_epoch.ncsc.mil> subject: Re: Proposed patch for libselinux Date: Fri, 22 Oct 2004 08:48:39 -0400
This is wrong; glibc directly provides [gs]etxattr for all modern glibc versions built against modern kernel headers; you don't need to use libattr. We originally used attr/xattr.h and then migrated a long time ago.
> +int getfileconperm(const char *path, int *perm) Directly storing an integer in the xattr? Endianness issues; you need to convert to a particular ordering before setting and convert back when getting. -- Stephen Smalley <sds@epoch.ncsc.mil> National Security Agency -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with the words "unsubscribe selinux" without quotes as the message.From: Daniel J Walsh <dwalsh_at_redhat.com> subject: Re: Proposed patch for libselinux Date: Fri, 22 Oct 2004 09:22:33 -0400
>On Thu, 2004-10-21 at 17:35, Daniel J Walsh wrote:
>>+int getfileconperm(const char *path, int *perm)
setfileconperm(path)
How about that? Dan -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with the words "unsubscribe selinux" without quotes as the message.From: Stephen Smalley <sds_at_epoch.ncsc.mil> subject: Re: Proposed patch for libselinux Date: Fri, 22 Oct 2004 09:44:14 -0400
Ok, the man page is out of date. ENOATTR doesn't exist anyway as a separate error code; the kernel returns ENODATA.
> I was looking at this as more of a TRUE/FALSE proposition. So maybe Possibly, with "fileconperm" replaced by "customcon" or similar, but don't you still want the stored "true" value to be consistent regardless of local cpu endianness? You could setxattr on a single byte I suppose to avoid the issue entirely. -- Stephen Smalley <sds@epoch.ncsc.mil> National Security Agency -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with the words "unsubscribe selinux" without quotes as the message.From: Daniel J Walsh <dwalsh_at_redhat.com> subject: Re: Proposed patch for libselinux Date: Fri, 22 Oct 2004 10:22:19 -0400
>On Fri, 2004-10-22 at 09:22, Daniel J Walsh wrote:
so
-- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with the words "unsubscribe selinux" without quotes as the message.From: Luke Kenneth Casson Leighton <lkcl_at_lkcl.net> subject: Re: Proposed patch for libselinux Date: Fri, 22 Oct 2004 16:56:40 +0100
char val; int err = getxattr(path, ..., &val, sizeof(val); *perm = val; return err; On Fri, Oct 22, 2004 at 08:48:39AM -0400, Stephen Smalley wrote:
> On Thu, 2004-10-21 at 17:35, Daniel J Walsh wrote: -- -- you don't have to BE MAD | this space | my brother wanted to join mensa, to work, but IT HELPS | for rent | for an ego trip - and get kicked you feel better! I AM | can pay cash | out for a even bigger one. -- -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with the words "unsubscribe selinux" without quotes as the message.From: Daniel J Walsh <dwalsh_at_redhat.com> subject: Re: Proposed patch for libselinux Date: Fri, 22 Oct 2004 15:55:43 -0400
Dan
-- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with the words "unsubscribe selinux" without quotes as the message.From: Daniel J Walsh <dwalsh_at_redhat.com> subject: Re: Proposed patch for libselinux Date: Fri, 22 Oct 2004 16:22:25 -0400
Attached wrong patch. Trying again
-- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with the words "unsubscribe selinux" without quotes as the message.From: Stephen Smalley <sds_at_epoch.ncsc.mil> subject: Re: Proposed patch for libselinux Date: Mon, 25 Oct 2004 10:52:37 -0400
The file_contexts configuration and setfiles were only intended to initialize the system, as previously noted. After installation, one should only do a make relabel upon a major policy upgrade, and even in that case, it would be better to selectively relabel based on the differences between the policies. At runtime, the file attributes will be set based on policy and in some cases refined by application and/or user knowledge subject to policy (setfscreatecon(3) or setfilecon(3)), reflecting the actual security properties of the objects. At any given time, you can find all files that are no longer consistent with the file_contexts configuration via setfiles -nv. You don't need a separate file attribute for that purpose, and the proposed flags attribute will only show files relabeled via chcon(1). Why should we treat such files differently than a file whose security context was set by any other application using setfilecon(3) or created after an explicit setfscreatecon(3) or even created in accordance with a file type transition rule? Typically, we don't want any of those files to be relabeled by a subsequent make relabel; we would only want them relabeled if there was a policy bug or application bug that had allowed those files to become mis-labeled in the first place at runtime, or if there has been a change in policy that affects those files/types. I'm inclined more towards the idea of alternatives in the file_contexts configuration, e.g. you specify a "primary" security context to be applied upon initialization, and you optionally specify alternatives (either individually or via equivalence classes) that are equally permissible. setfiles then defaults to applying the primary context, but will allow the file to remain unchanged if it has been set to any of the alternatives. -- Stephen Smalley <sds@epoch.ncsc.mil> National Security Agency -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with the words "unsubscribe selinux" without quotes as the message.From: Colin Walters <walters_at_redhat.com> subject: Re: Proposed patch for libselinux Date: Mon, 25 Oct 2004 11:31:36 -0400
> I'm inclined more towards the idea of alternatives in the file_contexts I think you're right; this handles the use cases I can think of for the custom attribute. -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with the words "unsubscribe selinux" without quotes as the message.From: Daniel J Walsh <dwalsh_at_redhat.com> subject: Re: Proposed patch for libselinux Date: Mon, 25 Oct 2004 14:00:18 -0400
>Let's step back for a moment from the implementation details and talk We need to change setfiles or some tool to look in /etc/selinux/*/context/files/* and load all policy files in the directory. Starting with file_context. Dan Dan -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with the words "unsubscribe selinux" without quotes as the message.From: Luke Kenneth Casson Leighton <lkcl_at_lkcl.net> subject: Re: Proposed patch for libselinux Date: Tue, 26 Oct 2004 15:21:26 +0100
it would appear, therefore, that no provision has been made for filesystem recovery. i find frequently that ext3 filesystem damage results in fsck.ext3 going "the extended attributes aren't valid: truncating". this leaves you with a (null) for an selinux access, as if you had run your system with a non-selinux kernel and written some files. under such circumstances, i find that the only [simple] means at present to recover such a damaged system is to run setfiles. l. -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with the words "unsubscribe selinux" without quotes as the message.From: Stephen Smalley <sds_at_epoch.ncsc.mil> subject: Re: Proposed patch for libselinux Date: Tue, 26 Oct 2004 10:13:01 -0400
star and (recently patched) rsync supports backing up security attributes from live filesystems.
> i find frequently that ext3 filesystem damage results in fsck.ext3 I've never seen this. Easily reproducible?
> this leaves you with a (null) for an selinux access, as if you had It seems that in that case, you would just want to relabel files that have no label at all, not any files that already have labels. It might be reasonable to have an option to setfiles to cause it to only relabel files that lack a SELinux attribute and leave all others intact. -- Stephen Smalley <sds@epoch.ncsc.mil> National Security Agency -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with the words "unsubscribe selinux" without quotes as the message.From: Luke Kenneth Casson Leighton <lkcl_at_lkcl.net> subject: Re: Proposed patch for libselinux Date: Tue, 26 Oct 2004 16:21:55 +0100
this was four/five months ago - if you recall i sent details about it at the time, and part of the "solution" was to upgrade the / partition to ext3 (!) let me try and think. the circumstances under which this occurred were with a 2.6.7 selinux kernel, with an ext2 filesystem, i would do a make relabel: something was going badly wrong (which i never tracked down, i just moved on...) such that on the next reboot, the filesystem could not be shut down properly... ... it was related to that bug about having a program that would not let go of a file handle on the /usr partition, such that at shutdown time the /usr partition was remounted read-only, such that on startup /etc/mtab had a record of /usr being mounted read-only... ... and permission to overwrite /etc/mtab was banned from initrc_t, such that it was not possible to clear /etc/mtab, such that no mounting /usr AT ALL was done because /etc/mtab had a record of /usr being mounted read-only... ... at that point, things got very bad, i would have to shut down the computer: /etc/mtab would be cleared at shutdown (because no programs were or could be using the /usr partition) at _that_ point, on the next reboot, the filesystem would be severely damaged, and _that's_ when fsck.ext2 found stacks of damaged extended attributes, and would truncate them. so um... easily reproducible? uhm... not really!!! slightly on the reassuring side:
/etc/init.d/mountvirtfs. yes. oh yes that's right it was to do with the detection of whether /etc was on a writeable partition by attempting to "touch /etc" from an initrc_t context - which of course will fail: the necessary change was to touch /etc/mtab instead.
l. -- -- you don't have to BE MAD | this space | my brother wanted to join mensa, to work, but IT HELPS | for rent | for an ego trip - and get kicked you feel better! I AM | can pay cash | out for a even bigger one. -- -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with the words "unsubscribe selinux" without quotes as the message.From: Luke Kenneth Casson Leighton <lkcl_at_lkcl.net> subject: Re: Proposed patch for libselinux Date: Tue, 26 Oct 2004 19:05:23 +0100
> i find frequently that ext3 filesystem damage results in fsck.ext3
correction: found.
> going "the extended attributes aren't valid: truncating". -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with the words "unsubscribe selinux" without quotes as the message.From: Nifty Hat Mitch <mitch48_at_sbcglobal.net> subject: Re: Proposed patch for libselinux -- xdr ??? Date: Fri, 29 Oct 2004 16:28:40 -0700
I am a little late to this party...
If all the data had an external data representation specification (man xdr) then the right thing could happen. In the world of storage area networks this could be an interesting topic when the raw bits of the disk are exposed to hardware with different data representations. -- T o m M i t c h e l l May your cup runneth over with goodness and mercy and may your buffers never overflow. -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with the words "unsubscribe selinux" without quotes as the message.From: Stephen Smalley <sds_at_epoch.ncsc.mil> subject: Re: Proposed patch for libselinux Date: Fri, 22 Oct 2004 09:23:40 -0400
"perm" suggests "permission" to me, not "permanent". Also, I'm not sure that "permanent" conveys the right sense; Colin's earlier suggestion of "customized" made more sense to me. Obviously, a kernel change is required here as well, as any other attribute in the security namespace should presently be restricted to CAP_SYS_ADMIN. The setxattr hook would need to check for this new attribute and apply a different check if you want non-root users to be able to do this, and we likely need a new permission for it then. Right? -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with the words "unsubscribe selinux" without quotes as the message.From: Daniel J Walsh <dwalsh_at_redhat.com> subject: Re: Proposed patch for libselinux Date: Fri, 22 Oct 2004 09:45:38 -0400
>On Thu, 2004-10-21 at 17:35, Daniel J Walsh wrote: I don't care what we call it. -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with the words "unsubscribe selinux" without quotes as the message.From: Stephen Smalley <sds_at_epoch.ncsc.mil> subject: Re: Proposed patch for libselinux Date: Fri, 22 Oct 2004 10:15:27 -0400
Debatable. Today, a domain may be able to relabel files, but an explicit relabel of the filesystem will always override those settings, which may be exactly what you want if you are doing a major policy upgrade. In general, one shouldn't be running setfiles on a system after installation except for major policy upgrades anyway. Allowing a domain to opt-out of subsequent relabels by default is new functionality; I think it requires a separate permission from relabelfrom.
> setfileconfixed? Do we think it possible that we may support other flags related to file contexts in the future? If so, then perhaps this should be a general flags field associated with the file context with a setfileconflags(path, flags), getfileconflags(path, flags) API and a single flag defined initially for marking the context as explicitly customized. -- Stephen Smalley <sds@epoch.ncsc.mil> National Security Agency -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with the words "unsubscribe selinux" without quotes as the message.From: Daniel J Walsh <dwalsh_at_redhat.com> subject: Re: Proposed patch for libselinux Date: Fri, 22 Oct 2004 10:24:39 -0400
>On Fri, 2004-10-22 at 09:45, Daniel J Walsh wrote: Dan -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with the words "unsubscribe selinux" without quotes as the message.From: Stephen Smalley <sds_at_epoch.ncsc.mil> subject: Re: Proposed patch for libselinux Date: Fri, 22 Oct 2004 10:30:00 -0400
We won't know until someone comes up with a second flag ;) I suppose we would start with a single permission for setting the flags at all, and then split it if necessary later. Of course, this takes us back to the endianness issue; you'll want to convert to a standard endianness for storage of the flags and convert back upon reading; see the libsepol code for reading and writing binary policies and note the use of cpu_to_le32 and le32_to_cpu (defined in src/private.h). -- Stephen Smalley <sds@epoch.ncsc.mil> National Security Agency -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with the words "unsubscribe selinux" without quotes as the message.From: Daniel J Walsh <dwalsh_at_redhat.com> subject: Re: Proposed patch for libselinux Date: Fri, 22 Oct 2004 14:01:03 -0400
Is this closer to what you want? Dan
-- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with the words "unsubscribe selinux" without quotes as the message.
|
|
Date Posted: Jan 15, 2009 | Last Modified: Jan 15, 2009 | Last Reviewed: Jan 15, 2009 |