Rich access control lists

Posted Oct 21, 2015 21:16 UTC (Wed) by dlang (guest, #313)
In reply to: Rich access control lists by dlang
Parent article: Rich access control lists

... besides, aren't we being told that the solution to all logging is to write to the systemd journal anyway?

Rich access control lists

Posted Oct 21, 2015 21:24 UTC (Wed) by fandingo (guest, #67019) [Link] (15 responses)

I'm not getting into another journal discussion with you. Anyways, there's plenty of programs that log data that doesn't need to or can't go through syslog. Applications running in containers are a prime example that typically lack syslog capabilities.

Not everything is centralized either. Additionally, you'd use this exact same append-only policy on the files that syslog does write, making your point moot. I don't know about you, but I don't run my applications or centralized syslog systems on a file server.

Rich access control lists

Posted Oct 21, 2015 21:31 UTC (Wed) by dlang (guest, #313) [Link] (14 responses)

There's no reason why syslog support can't be used in containers, either from running syslog inside the container, or having the host syslog daemon create /dev/log inside the container to capture the logs

Rich access control lists

Posted Oct 21, 2015 22:02 UTC (Wed) by fandingo (guest, #67019) [Link] (13 responses)

Jeez. I'm not arguing that it's technically impossible. The idea of running an unrelated logging daemon in a container is antithetical to the idea of containers. Passing through a socket isn't always appealing either. That being said, you're missing the point. Currently, if you want to securely write log messages to a daemon you need a different trusted daemon to do that, but if you're just logging to local files, I don't need that diversion. I just need a security mechanism that doesn't allow a compromised application to wipe out its log files; I don't need a logging daemon. In this example, a logging daemon is nothing more than a side-effect of an insufficient permission model.

Rich access control lists

Posted Oct 21, 2015 22:38 UTC (Wed) by Cyberax (✭ supporter ✭, #52523) [Link] (12 responses)

A compromised application can just spam the log files with 2Mb zero-filled data pages. It will scramble other writers and make analysis difficult.

And there are much better ways to do it already, anyway.

Do you have less contrived examples? Preferably not involving a "mainframe shared among faculty and students" textbook scenario that is pretty much irrelevant right now.

Rich access control lists

Posted Oct 21, 2015 23:03 UTC (Wed) by fandingo (guest, #67019) [Link] (11 responses)

You think containers are a contrived example? There are plenty of situations that need WORM semantics where append-only is important. Any transaction processing system that appends to a file would benefit from that security.

> A compromised application can just spam the log files with 2Mb zero-filled data pages. It will scramble other writers and make analysis difficult.

That's better than a 0B file that was maliciously truncated...

Rich access control lists

Posted Oct 21, 2015 23:19 UTC (Wed) by dlang (guest, #313) [Link] (3 responses)

If you trust the kernel and permissions to protect the file from being truncated once you have a malicious actor taking over your binary, you have a lot more trust than I do.

Anything important like that sort of log data, I want off on a separate machine.

Rich access control lists

Posted Oct 22, 2015 0:04 UTC (Thu) by fandingo (guest, #67019) [Link] (2 responses)

> Anything important like that sort of log data, I want off on a separate machine.

I already addressed this in a previous comment.

>> Additionally, you'd use this exact same append-only policy on the files that syslog does write, making your point moot.

Wherever that data hits disk, it's advantageous to be able to restrict to `append_data`, even when that writing is happening on a separate system.

Rich access control lists

Posted Oct 22, 2015 0:09 UTC (Thu) by dlang (guest, #313) [Link] (1 responses)

> Wherever that data hits disk, it's advantageous to be able to restrict to `append_data`, even when that writing is happening on a separate system.

advantageous, yes

but worth how much in the face of the added complications, bugs and performance hit?

Also, to make use of this, the applications are going to have to be modified in linux-only ways. Some apps won't care, but others try to be cross platform, so this sort of churn won't be welcome.

Rich access control lists

Posted Oct 22, 2015 0:56 UTC (Thu) by fandingo (guest, #67019) [Link]

> but worth how much in the face of the added complications, bugs and performance hit?

It's worth 42. I don't know how to answer the obviously loaded, rhetorical question. You'll need to offer data about performance implications before I'll get into that topic; it's just FUD otherwise.

> Also, to make use of this, the applications are going to have to be modified in linux-only ways. Some apps won't care, but others try to be cross platform, so this sort of churn won't be welcome.

For the most part, this isn't something that applications will interact with at all. (I suppose beyond EACCESS when there is a violation, but they have to deal with that anyways.) It will be handled just like SELinux policy: The Linux distribution writes and maintains it.

There is specialized software that may need to interact with Richacl specifically, but I just don't see it being a major problem. The only places where it may cause a problem is when a project is sloppy with it's open(2) mode flags, which should be tightened regardless of Richacl. If a piece of software is diligent, writing a policy for that software package isn't any challenge.

Rich access control lists

Posted Oct 22, 2015 0:17 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link] (6 responses)

> You think containers are a contrived example? There are plenty of situations that need WORM semantics where append-only is important. Any transaction processing system that appends to a file would benefit from that security.
If you want real WORM for auditing purposes then file permissions are not enough.

Append-only mode also does not guarantee atomicity, so I'm curious to see the actual systems that depend on it. I'm not aware of anything non-trivial.

Rich access control lists

Posted Oct 22, 2015 0:27 UTC (Thu) by smckay (guest, #103253) [Link] (1 responses)

Does HDFS count? As appending is the only kind of writing you can do. ;)

Rich access control lists

Posted Oct 22, 2015 0:29 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link]

As far as I know, no HDFS implementations depend on filesystem-level append-only permissions.

Rich access control lists

Posted Oct 22, 2015 1:13 UTC (Thu) by fandingo (guest, #67019) [Link] (3 responses)

I neither said nor implied it did. IO synchronization is a separate problem. Perhaps down the road, they can add additional Richacl types (unsigned int leaves a lot of available flags) for open(2) modes like O_SYNC (and other associated syscalls) to allow Richacl policy to require or prohibit that option.

> so I'm curious to see the actual systems that depend on it.

I'm not sure any piece of software itself could "depend" on it. From the software's perspective, it's just eliminating extraneous syscalls and mode flags. It's the software distribution's (or perhaps the adventurous sys admin's) job to write and distribute a policy. The policy separation and delegation to distributions is same as SELinux.

Rich access control lists

Posted Oct 22, 2015 1:30 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link] (2 responses)

And to guarantee that the entries are also semantically correct, perhaps we can add another permission to attach an XML (or even ASN.1) schemas to files?

Of course, some people might also forbid any file activity on Sundays, so we need a special permission for that as well.

Rich access control lists

Posted Oct 22, 2015 1:50 UTC (Thu) by fandingo (guest, #67019) [Link] (1 responses)

Sure, if you want to do that, although some file systems have xattr length limitations. I'd treat ACLs the same as LSMs: Pick anyone you want (and stack them if you like and support is implemented). The data will be stored in xattrs defined by that ACL module, and a file system feature flag can be used to force (or indicate if a bypass kernel cmdline / config option is set) a kernel to use that ACL module.

Nonetheless, I doubt you'd have many people in such a scheme. But, let's dial it back from absurdity.

Rich access control lists

Posted Oct 22, 2015 22:58 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link]

No. Complex LSMs proved to be a total failure - NOBODY understands how SELinux works, so on most systems it just sits idly and eats resources.

At least with modebits I can understand what's happening immediately. With Windows ACLs you can't do that - you have to carefully evaluate the rules, keeping their order in mind. POSIX ACLs are ok-ish, they at least play nicely with the regular Unix permissions.

And your examples are so far extremely poor. If you need to constrain a daemon to use only O_APPEND - then write an LSM module for that. No need at all to rape file permissions. And if you are doing it over NFS then get a proper rsyslog, for FSM's sake.

So what are other examples, apart from the contrived O_APPEND?