Casper.Dik at Sun.COM wrote:
>
>> But what we don't provide that BSD run-levels do, is an administrative
>> way to make sure that the system has entered such a "secure run-level."
>> In Solaris that would be done by making sure that no process has (and
>> therefore can't get) some privilege in its L/P/E sets, no? But we don't
>> have an SMF service, say, that we could enable, that would allow this.
>
> I'm aware of that; but BSD secure-levels have many shortcomings that
> make it impossible to retrofit this to Solaris, except if we limit
> it to a tiny subset of buttoned down appliances.
>
> But we can provide secure-levels on the per-process basis and continue
> to have Solaris work; with "work" meaning the ability to add devices,
> disks, device drivers, live-upgrade, create zpools, etc.
>
> All you need to do is prevent users from entering the system with an
> unrestrictive limit set; the OS itself and the core components will
> need to continue to be able to modify essentially all of the OS if
> we want to have any form of "dynamic OS".
>
> I don't see that as a problem. I see secure-levels as a useful hack,
> but believe that the boundary of protection should not be the kernel;
> it should be the kernel and the associated processes such as SMF, FMA,
> DR, etc.
>
>> Now, suppose that we had such a service. Then we could have a system
>> running without any process with PRIV_FILE_FLAG_SET in any priv set, but
>> now operations that normally need all privs cannot be done, and if the
>> intent in dropping PRIV_FILE_FLAG_SET was only to make sure that certain
>> files were immutable until the next boot then dropping that priv will
>> have accomplished more than that. I'm thinking of writing to files
>> owned by UID 0, which requires all privs, not just PRIV_FILE_DAC_WRITE.
>>
>> OTOH, perhaps that should be the intent in dropping PRIV_FILE_FLAG_SET:
>> to prevent not just writes to immutable files and so on but also to
>> prevent all operations which would require the caller have all privs.
>
> But unfortunately it would prevent all such operations which may not
> be what you want.
>
> Before I want to see these privileges for immutable files I want to
> know more about what we are going to do with this and what our direction
> with this is.
>
> For now, the primary use of immutable files is the fact that they allow
> you to mark files as "special" and that you cannot overwrite or remove
> them by accident (do we disallow removal for immutable files?)
>
> To this end I think just a "set" privilege and requiring "ALL" to remove
> them.
>
> For the remainder, the whole picture should include a discussion about
> signed files (which should have immutability as a property if you ask me),
> secure execution and hardened operation.
>
>
> Casper
>
Combining the responses from the recent questions:
Privileges (Scott Rotondo, Casper Dik):
The project team is willing to remove the PRIV_FILE_FLAG_CLEAR
privilege and require a process to have "all" privileges in order to
clear attributes such as immutable.
Uses of system attributes other than CIFS (Scott Rotondo):
There are certainly other uses for system attributes such as
virus scanning, HSM applications, etc. The CIFS server is
called out because it is the first project requiring system
attributes in Solaris.
Protected namespace (Scott Rotondo, Nico Williams):
The SUNW* convention is documented in fsattr(5).
Creating attribute files with system attribute names (Hugh McIntyre):
A user is free to create whatever extended attribute file s/he wants
but that doesn't mean that Solaris will recognize it as a system
attribute.
As stated in section 4.1 of the spec:
Instead of exposing each individual system attribute as a named
object, we are exposing named sets of system attributes as views into
the system attribute space. This is being done to minimize clutter
in the name space.
Manipulating attributes in a non-Solaris environment (Casper Dik):
The system attributes do not exist in separate attribute files (such
as SUNW_IMMUTABLE). The individual system attributes are represented
as nvpairs within SUNWattr_rw and SUNWattr_ro. See section 4.1 for
further details.
The CIFS client/server only knows about the DOS level attributes.
Attributes such as immutable are not part of the SMB protocol. If a
CIFS client attempts to update an immutable attribute in SUNWattr_rw
attribute file then that process would need the appropriate
privileges in the cred created by the CIFS server to manipulate those
attributes.
See the last paragraph of section 4.1 and all of section 4.3.1 for
more on NFS support.
Removal of "immutable" files (Casper Dik):
A file marked as "immutable" cannot be removed.
Signed files (Casper Dik):
Signed files are not part of this case. We are laying the foundation
for future projects to take advantage of these attributes.
-Mark
