pc@hillside.co.uk (Peter Collinson) (06/28/91)
Submitted-by: pc@hillside.co.uk (Peter Collinson) USENIX Standards Watchdog Committee Stephen R. Walli <stephe@usenix.org>, Report Editor Report on POSIX.6: Security Extensions Ana Maria De Alvare <anamaria@sgi.COM> reports on the April 15-19, 1991 meeting in Chicago, IL: Summary The POSIX.6 group spent the week preparing draft 11 of their document for internal ``mock'' ballot. They began work on their test assertions document. The IEEE balloting group formation process is now officially closed. The Privilege subgroup discussed a proposal to remove the global constant POSIX_PRIV_EFFECTIVE from the draft. The Audit subgroup will not be able to address the portable audit format before balloting begins, but they will define the audit trail header. The liaison group between POSIX.6, POSIX.7 (System Administration) and the Distributed Services groups will report back to the TCOS-SS Sponsor Executive Committee (SEC) at the July meeting, recommending a new coordination group be formed. Report The POSIX.6 group met for the entire week in Chicago. The group concentrated their efforts on cleaning up draft 10 of the document. The balloting solicitation process has been closed. If you requested to be in the balloting group, please confirm you are on the list by calling the IEEE, Anna Kacznarek (908-562-3811). A major action item was the creation of the test assertions document for POSIX.6. This will be a separate parallel document. The definitions and overview sections of POSIX.6 were addressed this week. Each subgroup will be responsible for creating the test assertions for the document sections they are working on. The subgroups will maintain consistency between the test assertions and the POSIX.6 document. Modifications to the POSIX.6 document will signal modifications to the test assertion document. In the next meeting we are planning to integrate test assertion sections from POSIX.3.1 (Test Assertions for POSIX.1) into our document. Dave Rogers (Data Logic) and I are co-chairing this effort. If you are interested in participating in the test assertion work, please let me know (anamaria@sgi.com or 415-335-7309). POSIX.6 will mock ballot draft 11 within the working group before July. We plan to review written comments to this mock ballot at the July meeting. If all the written comments are addressed, we will try to ship the document for IEEE ballot after July. We could then start resolving the ballot objections at the October meeting. Privileges Secureware's VP of Marketing proposed eliminating from the standard the system global constant, POSIX_PRIV_EFFECTIVE, which turns on/off all the privileges already set by the process or set by the file privileges in effect. The system global constant can increase or decrease the effective privilege set. The argument against the system global constant was that when POSIX_PRIV_EFFECTIVE is on, a privilege aware program (i.e. a trusted application) will have effective privileges on before it uses them. This violates the concept of least privilege, since the process contains more privileges than it needs. It is the responsibility of that trusted application to turn off all effective privileges and then turn them on one by one as it needs them. Another argument against the global constant is that it gives the system manager a central point to turn on/off privileges. With the new scheme, programs that turn ``priv_effective'' on are consciously given permission to do so, a point that brings higher granularity. A vote was taken and the group decided to eliminate the system global constant, POSIX_PRIV_EFFECTIVE and use ``priv_effective'' as an additional file privilege. The standard now contains three privilege sets associated with a process, (inheritable, permitted, effective) and two privilege flags (``allowed'' and ``forced'') associated with each privilege on a file. The two file privilege flags are: - Allowed - a flag associated with a file privilege that will authorize it to be on during the execution of that program, if the process possesses that privilege. - Forced - a flag associated with a file privilege that will be on during the execution of that program even if the process does not possess that privilege. This allows for old setuid programs to continue to work under POSIX.6 without source code modifications. The new file privilege ``priv_effective'' will turn on the process's effective privilege set. If your file has ``priv_effective', your file makes effective all of the privileges that are on after calculating ``allowed'' and ``forced'' flags against the process's inheritable flags. A process possesses three sets of privilege flags: inheritable, permitted, and effective. For a process to access a file, the process's effective privilege set (built from its inherited and permitted sets) is tested against the file's privilege set. To be able to pass a privilege from the inheritable set (from its parent process), to the permitted set, the system will test the process's inheritable privilege against the file's ``allowed'' and ``forced'' flags for that privilege. If the file privilege's ``allowed'' flag is set, then the privilege is turned on in the process's permitted set. If the file privilege's ``forced'' flag is set, then the privilege is turned on in the process's permitted set even if the privilege was not inherited. To be on in the process's effective set, the system compares the inheritable privilege against the file's ``allowed'', and ``forced'' flags. If the process's inherited privilege is in the file's ``allowed'' set and the file's ``priv_effective'' privilege is set, then the privilege becomes effective. If the process's inherited privilege is in the file's ``forced'' set and the file's ``priv_effective'' privilege is set, then the privilege becomes effective. In other words, to be set effective the file's ``priv_effective'' flag must be on. Some of you might think that this scheme still gives me a trusted application with effective privileges turned on. The list of programs with privileges turned on, however, is smaller than using the system global constant. In addition the effective privilege set is not on for all processes. All of this can become very confusing. Sometimes I have trouble understanding all of the benefits. Every time I read the document new questions come to mind. Sometimes I agree and other times I don't. Hopefully the mock ballot will call attention to any ambiguous areas left in the draft document. Access Controls Both the discretionary and mandatory access control subgroups (DAC and MAC) are ready for our internal mock ballot. The primary DAC related changes for draft 10 concerned default access control list (ACL) behaviour and the command chacl which changes the ACL. The MAC group had no hot issues to discuss. 1. Audit The Audit group finished modifying the draft and writing the rationale for integrity protection, header flexibility, and cross references. The group felt they cannot address the portable audit format before balloting, however, they are planning to define the audit trail header containing: - POSIX audit indicator field, - version ID, - data format indicator (type XDR, little endian, big endian), - time zone offset, - machine id, and - audit style. The audit file format remains up in the air. POSIX.6/POSIX.7/Distributed Services Liaison The liaison group met on Wednesday. Mike Ressler stepped down and I became the chair of the group. We discussed the status of the group and what we should bring forward to the TCOS-SS Sponsor Executive Committee (SEC). Everyone agreed that we have enough information to create a report to the SEC discussing the problems we discovered and to make recommendations. I will present our report at the July meeting with the help of the liaison group. The report will include an overview of each subgroups objectives, a list of problem areas discovered during our meetings, and recommendations to solve these problems. I hope that SEC acts upon our recommendations. One recommendation we want immediate action on is the lack of a mechanism to ensure that one POSIX extension can interoperate with another POSIX extension. An example of this interoperability issue is having POSIX.6 and POSIX.8 (Transparent File Access) on the same system. We are proposing a new group be formed which will check that POSIX standards interoperate with each other or to at least document where different POSIX extensions cannot interoperate. Volume-Number: Volume 24, Number 29
jmcarli@ns.PacBell.COM (Jerry M. Carlin) (06/28/91)
Submitted-by: jmcarli@ns.PacBell.COM (Jerry M. Carlin) The BIG problem I see with 1003.6 is lack of I&A; identification and authentication. What has been lacking for a LONG time is decent login.c, passwd.c etc functionality including ability to develop local rules passwords. We've seen a number of reimplementations of these functions on the net precisely because the current ones are so bad & inconsistant. The group has worked very hard on things that I see as having little if any commercial usefulness such as MAC. I suppose MAC will be useful to sell to the government but MAC is not useful to the world of applicatons, transactions and databases. This is like building a vault but putting no lock on the door or at least leaving it to someone else to worry about the lock. I'm not sure if P1003.6 committee is coming up with a horse, camel or genetic combination but it sure has no head! -- Jerry M. Carlin (415) 823-2441 jmcarli@srv.pacbell.com To dream the impossible dream. To fight the unbeatable foe. Volume-Number: Volume 24, Number 30