| View previous topic :: View next topic |
| Author |
Message |
ulenrich
Veteran
Joined: 10 Oct 2010
Posts: 1480
|
 Posted: Sun Apr 05, 2015 9:50 pm Post subject: |
 |
|
| mv wrote: | Who really understands a little bit about security knows how to get security in reality:
- Make privilege separation absolutely strict. Do not build any backdoors to circumvent this and that restriction in the name of user's convenience. A thing which raises privileges like policykit or even dbus is an absolute no-go.
- Keep the tasks running with high privileges extremely tiny and provably correct. Normally, no communication should happen between high privilege tasks and any other task. Do anything to avoid this.
- If you are in the absolute exceptional situation of a very complex setup where this cannot be avoided, keep this communication as simple and safe as possible, making sure that no race condition or similar tihings can ever arise. However, when you cannot avoid it, almost surely you have already done a severe mistake and should better think over your security concepts.
We all know that systemd&friends have broken all these rules dozens of time, shrugging it off as if it were nothing.
Using a technique afterwards which can be used as a security measurement - if carefully implemented and used as a basis (and not the other way 'round) - does under these circumstances not increase security at all, but just serves to give technically unskilled people a healthy feeling in the stomach: All the race conditions and bugs due to mere complexity allowing privilege escalates still exist and are in principle unfixable. An apparent separation of low privilege tasks helps nothing to improve the situation: First, the existing gapping security holes must be fixed. That is, everything which systemd&friends currently are, must be completely removed or at least conceptionally completely re-done (and then in non-broken way). |
I found in a Debian Changelog, which presumably shows what you talking of | Quote: | udisks2 (2.1.5-2) experimental; urgency=medium
* Team upload.
* Treat devices as "on the same seat" if the requesting uid owns
the active login session on the device's seat. This means that shared
services run by the user's `systemd --user`, such as the dbus-daemon
run by dbus-user-session and the D-Bus or systemd services that
it starts, can manipulate the user's devices even though those are
not associated with any particular login session or seat.
(Closes: #780004)
-- Simon McVittie <smcv@debian.org> Tue, 31 Mar 2015 19:16:58 +010 |
Is this exactly what you are talking about?
But when you say:
"Normally, no communication should happen between high privilege tasks and any other task. Do anything to avoid this."
Could you tighten that claim, I mean for example: If I ask my system to open my files, isn't it a common and needed procedure? |
|
| Back to top |
|
 |
steveL
Watchman
Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery
|
| Posted: Mon Apr 06, 2015 4:26 am Post subject: |
|
|
| @mv: good luck going round the mulberry bush ;) |
|
| Back to top |
|
|
mv
Watchman
Joined: 20 Apr 2005
Posts: 6749
|
| Posted: Mon Apr 06, 2015 5:57 pm Post subject: |
|
|
| ulenrich wrote: | | Is this exactly what you are talking about? |
Yes, bugs of such kind. The list of such bugs is (and will be) endless.
Here are a few other similar bugs which I had collected several months ago within five minutes when I evaluated the security of systemd/polkit for my usage:
Something from redhat
Tracker with dozens other related bugs for polkit
Some systemd related bugs
Even non-polkit packages can trigger privilege escalations
I did not check the bugs in detail, so maybe some are not really relevant or cannot be exploited. But this is not really important for my arguments. It is also completely irrelevant whether these bugs are fixed, meanwhile.
In fact, the problem is not each individual bug: It is normal that software of the complexity of sytemd+dbus+policykit+javascript+udisks+dhcp+logger+... has hundred or thousands of more or less exploitable bugs. Moreover, each new version will introduce dozens or more new bugs (besides closing dozens or more known bugs). I would not hold this agains this software.
The problem is that the very concept of systemd+... (and especially of all its coupling) means that each individual such bug can lead (not so unlikely) to the worst case when you want to run a safe system: It might allow the attacker to execute arbitrary code with arbitrary permissions.
In this sense, all of these bugs are not to be considered as indivial bugs but are the consequence of the fundamental misconception of the whole software bundle.
| Quote: | | If I ask my system to open my files, isn't it a common and needed procedure |
To open your files, you do not have to communicate with high-privilege tasks. (This is not completely correct: At some point, you need system calls. However, this is what I meant by "keeping the high-privilege tasks as small as possible": You only have to rely on relatively small, as non-complex as possible, well-tested since years, functionality of the kernel. Compared to the systemd+dbus+.... monstrosity, this is practically nothing.)
The point is that the intention of systemd+... is not only to allow you to open your files, but simultaneously, your sticks, your videocard, your soundcard, your ...
The safe (and Unix) way is to not allow you access to this at all.
Full stop.
No access.
This is not convenient and window-ish, but this is safe and good.
When access is absolutely needed, the administrator has to think about a safe way how you can get it. In some cases, this is possible with sudo or pam, in some cases there is no convenient solution at all. Thus, the pendulum "security <-> convenience" is in Unix always to the left, and you should move it to the right only as far as it is absolutely necessary.
The Windows philosophy was always the opposite: Everything should appear simple to the user, so they moved the pendulum "security <-> convenience" from the very beginning into the opposite direction until it sticks the border.
And this is also exactly what systemd+... has done: Practically, security is already no longer existent once you use systemd&friends, because everything can be vulnerable with every bug. The advantage is that you have full convenience: Every tiny subjob has full access to all your stick/clock/disk/battery etc, you do never have to enter your password if you need mounting such a thing or want to do heavy manipulation with the sound output, freeze your system, toggle thermal sensors, mount encrypted data, or whatever. Convenient, but completely unsafe.
And the bad thing: You cannot just move the pendulum "security <-> convenience" back (unless you remove all of systemd&friends): Any attempt to do so would just make you loose convenience without gaining the security back, because the underlying system with the holes already is there.
But when I hear now that systemd is supposed to make your system more secure, because they "add" security feature X and Y (to a fundamentally unsafe superstructure), I can only laugh (or actual cry) about such obvious lies.
The problem is not that feature X and Y - if used correctly and in a fundamentally safe environment - would not increase security, but to use them in an unsafe environment is just eyewash |
|
| Back to top |
|
|
steveL
Watchman
Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery
|
| Posted: Mon Apr 06, 2015 6:57 pm Post subject: |
|
|
Great summary, mv.
I'd just add that a syscall is not "talking to a privileged task"; it's a syscall, and the privilege separation is inherent in the syscall (or user-supervisor mode), and further the kernel does permission-checking all the time.
That's why it's a mistake to reinvent the kernel in userland, as dbus does in the realm of IPC, and polkit does in the realm of security (very badly.) If you want more flexibility you use PAM, which illustrates the point mv is making: if you write security-sensitive code, it MUST be walled off, to keep it "tiny and provably correct."
systemd and polkit add nothing to a correctly-setup machine, afaic, apart from lock-in and a bundle of security issues, by design.
As for containers I have nothing against them; but they do not justify, nor even require systemd at all. All you're talking about really, is linux finally catching up with BSD jails, and systemd again adds nothing but liabilities. |
|
| Back to top |
|
|
ulenrich
Veteran
Joined: 10 Oct 2010
Posts: 1480
|
| Posted: Mon Apr 06, 2015 11:02 pm Post subject: |
|
|
Computing is all about communication between different tasks.
| mv wrote: | | Normally, no communication should happen between high privilege tasks and any other task. |
Normally there is ever and ever such talk between components.
| steveL wrote: | | I'd just add that a syscall is not "talking to a privileged task"; it's a syscall, and the privilege separation is inherent in the syscall (or user-supervisor mode), and further the kernel does permission-checking all the time. |
A syscall is a typicall kind of such talk to a privileged task. Regarding filesystem access the talk is well defined and privilege separation works perfectly. Because the problem of communication is solved in this case you arbitrary define it NON-communication. Why? You hide away what otherwise could hold as an example for other communication in the system.
Claiming "sudo" is a secure alternative is the most dangerous claim one can make. Normal non experts should not try to configure "sudo" on a secured system (although I consider all of Gentoo users to be experts). To make "sudo" talking to your machine in a secure way you need a level of expertise. I don't know much about polkit. But all it should do is to generate valide and secure sudo strings to enable normal users to complete comon tasks. Or any equivalent technique enabling normal users to handle their device without the need of another expert administrator. A well configured polkit system should be nothing more than an expert system in that regard. If polkit cannot be secured to be the expert system Linus T. needs for his daughter allowing her at school to enable a printer (That was his outcry against Redhat some years ago as I remember): You have to invent a better way!
@mv, do you remember having said in our mail contact you would not allow dbus messages between normal users and privileged system processes, but dbus messaging between equal privileged users only? Now think one of these users has a valueable "sudo" privilege without any password. If the other user knows about it and has malicious intentions? If you claim inter process communication (ipc) is flawed by nature or principle!
Also the premise it is all about communication between unprivileged and privileged partners is flawed: In the real world you often cannot decide what role in effect is the more privileged. At the end if there is any unforeseen security hole at some point it might be the contrary you would have expected. |
|
| Back to top |
|
|
steveL
Watchman
Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery
|
| Posted: Tue Apr 07, 2015 7:40 am Post subject: |
|
|
| steveL wrote: | | I'd just add that a syscall is not "talking to a privileged task"; it's a syscall, and the privilege separation is inherent in the syscall (or user-supervisor mode), and further the kernel does permission-checking all the time. |
| ulenrich wrote: | | A syscall is a typicall kind of such talk to a privileged task. Regarding filesystem access the talk is well defined and privilege separation works perfectly. Because the problem of communication is solved in this case you arbitrary define it NON-communication. Why? You hide away what otherwise could hold as an example for other communication in the system. |
No it's a way to talk to the kernel, not some other userland process.
That you've missed this is the central problem with your entire post.
| Quote: | | Claiming "sudo" is a secure alternative is the most dangerous claim one can make. |
What are you on about now? As usual you present a strawman, and witter on as if you know what you're talking about, which you patently do not. For a start, no one even brought up sudo that I can see; you did. Secondly, alternative to what? polkit? Puhleez.
| Quote: | | Normal non experts should not try to configure "sudo" on a secured system (although I consider all of Gentoo users to be experts). To make "sudo" talking to your machine in a secure way you need a level of expertise. I don't know much about polkit. But all it should do is to generate valide and secure sudo strings to enable normal users to complete comon tasks. Or any equivalent technique enabling normal users to handle their device without the need of another expert administrator. A well configured polkit system should be nothing more than an expert system in that regard. |
This is what I mean about you patently do not know what you're talking about. Lots of vague hand-waving and "should" based on complete lack of knowledge.
| Quote: | | If polkit cannot be secured to be the expert system Linus T. needs for his daughter allowing her at school to enable a printer (That was his outcry against Redhat some years ago as I remember): You have to invent a better way! |
Yeah, well dbus and polkit sure as hell ain't it.
This discussion has been gone over to death in other threads about systemd and (k)dbus. I don't see why we should repeat it here, just so you can spread more vague disinformation; try going to the other threads to remind yourself of it instead.
| Quote: | | Now think one of these users has a valuable "sudo" privilege without any password. If the other user knows about it and has malicious intentions? If you claim inter process communication (ipc) is flawed by nature or principle! |
*sigh* no one claimed IPC is flawed by principle (so yaf strawman there.) Secondly, sudo does not come with any holes out of the box: you have to configure it to allow, eg wheel access.
So your argument appears to be "the admin can configure a hole with sudo, therefore it's ok for systemd, polkit and dbus to open everything from the beginning," in what everyone knows to be more insecure, and even though it's up to the admin what they do with their machine (unless they're running systemd as pid1, in which case many more vectors and a much larger surface to attack are mandatory) and the "hole" is anything but; it's been deliberately configured like that (instead of using js, of all things, to do the same.)
| Quote: | | Also the premise it is all about communication between unprivileged and privileged partners is flawed: In the real world you often cannot decide what role in effect is the more privileged. |
More nonsense; the kernel is privileged by definition, and we know damn well when a syscall happens, so this is pure rubbish afaic, given the context of the discussion you're wading into.
| Quote: | | At the end if there is any unforeseen security hole at some point it might be the contrary you would have expected. |
Lol; yes by definition. So this is more vague that simply pretends to an air of authority, while adding nothing but FUD to the conversation. |
|
| Back to top |
|
|
229566
Tux's lil' helper
Joined: 16 Aug 2010
Posts: 127
|
| Posted: Tue Apr 07, 2015 10:48 am Post subject: |
|
|
While Polkit itself may have been badly implemented, a mechanism like that is definitely required because the basic DAC (Discretionary Access Control) is insufficient. Then again we do have MACs (Mandatory Access Control) but those don't cut it either as they're conceptually not designed to control concurrency only context of access. Eg. ability to suspend in multi-seat.
Meanwhile, the notion that low privileged process should not talk to a high privileged one is pure nonsense. What really should be considered is the interface of the communication. For instance, there is a difference between:
1. a lo-priv process being able to call and execute /usr/sbin/useradd
2. a lo-priv process telling some central authority that it needs user X, with properties Y and Z, with no ability to execute any code directly
While systemd itself may be poorly implemented, I think in 2015 we cannot deny the fact that relying groups, sudo and suids is insufficient. It may be sufficient for that particular example (actually calling useradd), but in general a central authority that implements policies beyond DAC and MAC is definitely needed.
Also, sudo is a totally wrong concept in 2015. It was designed to keep users at bay, in the times when the word "malware" and "trojans" did not exist. It gives you all or nothing hi-priv access! Executing a trojaned bin with sudo will pwn your system sooner than you can say omg! Because sudo is DAC and we really need an advanced MAC nowadays. |
|
| Back to top |
|
|
bstaletic
Apprentice
Joined: 05 Apr 2014
Posts: 253
|
| Posted: Tue Apr 07, 2015 11:27 am Post subject: |
|
|
GrueXYZ,
Sudo can be configured to per user and per command. So user "bstaletic" could have access to useradd but not to eix-sync, yet user GrueXYZ could have access to dd but not to emerge. Any of those could require password of target user or of running user or could not require password in the first place. Also user could be allowed to run a command as another user, but not as root or as another group but not as wheel/root.
To conclude, sudo does not mean all or nothing. |
|
| Back to top |
|
|
229566
Tux's lil' helper
Joined: 16 Aug 2010
Posts: 127
|
| Posted: Tue Apr 07, 2015 11:40 am Post subject: |
|
|
| bstaletic wrote: | | To conclude, sudo does not mean all or nothing. |
Of course it does, it elevates you temporarily to root in order to execute something. It does check whether your user has the right to execute that particular thing as root, but it doesn't go beyond that. You're root for the duration of execution of what you called. In that respect it's all or nothing superaccess, because whatever you run will be run as root.
Case in point, cat. sudo cat /etc/shadow. What does sudo protect? Access to the cat bin or access to /etc/shadow? Obligatory xkcd: https://xkcd.com/149/
Contrast that to a MAC policy that says "Okay, you're root but I don't care. All you can do in this context is add a user, but you can't read and feed /etc/shadow into your favourite password cracker" |
|
| Back to top |
|
|
bstaletic
Apprentice
Joined: 05 Apr 2014
Posts: 253
|
| Posted: Tue Apr 07, 2015 12:16 pm Post subject: |
|
|
That command would not protect against anything.
Let's say I have a two users on my system (excluding root). Here's the hypotetical content of /etc/sudo
| Code: |
root ALL=(ALL) ALL
user1 user2=(ALL) ALL
user2 user1=(ALL) ALL
|
In this case noone except root using sudo would be able to use dd (or any other command requireing elevated privilages). So your command (with cat) wouldn't even execut if run by user1 or user2 as they do not have permissions to execute as root.
On the other hand, sudoers as following
| Code: |
root ALL=(ALL) ALL NOPASSWD
%wheel ALL=(ALL) ALL NOPASSWD
|
is extemely dangerous |
|
| Back to top |
|
|
229566
Tux's lil' helper
Joined: 16 Aug 2010
Posts: 127
|
| Posted: Tue Apr 07, 2015 1:48 pm Post subject: |
|
|
| bstaletic wrote: | | So your command (with cat) wouldn't even execut if run by user1 or user2 as they do not have permissions to execute as root. |
Which is irrelevant. My point is that sudo gives you the entire privilege of the target user (all or nothing that I wrote, perhaps I wasn't clear). You become the target user for the, and during the execution of the target binary.
My point is, if the target binary is trojaned, for example, your user1 can do and access anything user2 can, regardless of your sudo confinement.
A MAC policy, on the other hand, can say that user1 can only execute binary X as user2, in the context of whatever is minimally required for X to run and do the task. Nothing else. Your user1 does not become user2, it only does that minimal set of tasks. |
|
| Back to top |
|
|
depontius
Advocate
Joined: 05 May 2004
Posts: 3509
|
| Posted: Tue Apr 07, 2015 3:45 pm Post subject: |
|
|
Which is part of how we get to where we are. There seem to be two major camps:
1 - Systemd is the solution to all Linux problems, abandon your woeful ways and Embrace the Change!
2 - Systemd is junk, we're just fine the way we are.
The third camp gets little notice in the shuffle...
3 - Systemd is junk. While there are problems with the way things are now, they are at least workable, and systemd is not the solution. (There is room for improvement.)
_________________
.sigs waste space and bandwidth |
|
| Back to top |
|
|
mrbassie
l33t
Joined: 31 May 2013
Posts: 781
Location: over here
|
| Posted: Tue Apr 07, 2015 6:23 pm Post subject: |
|
|
| GrueXYZ wrote: | | bstaletic wrote: | | To conclude, sudo does not mean all or nothing. |
Of course it does. |
| Code: | ~ $ sudo echo 3 > /proc/sys/vm/drop_caches
bash: /proc/sys/vm/drop_caches: Permission denied |
|
|
| Back to top |
|
|
Naib
Watchman
Joined: 21 May 2004
Posts: 6051
Location: Removed by Neddy
|
| Posted: Tue Apr 07, 2015 6:39 pm Post subject: |
|
|
Now wrap the echo and redirect in round brackets. Sudo escalates one process, the redirect and pipe are no longer part of that single process
_________________
| Quote: | | Removed by Chiitoo |
|
|
| Back to top |
|
|
mrbassie
l33t
Joined: 31 May 2013
Posts: 781
Location: over here
|
| Posted: Tue Apr 07, 2015 6:49 pm Post subject: |
|
|
| I guess I should read sudo mastery. |
|
| Back to top |
|
|
steveL
Watchman
Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery
|
| Posted: Tue Apr 07, 2015 9:00 pm Post subject: |
|
|
| @depontius: you're doing it again (allowing the systemdiots to frame the discussion.) In fact there isn't anyone in group 2 whatsoever, and never has been. |
|
| Back to top |
|
|
229566
Tux's lil' helper
Joined: 16 Aug 2010
Posts: 127
|
| Posted: Tue Apr 07, 2015 10:27 pm Post subject: |
|
|
| mrbassie wrote: |
| Code: | ~ $ sudo echo 3 > /proc/sys/vm/drop_caches
bash: /proc/sys/vm/drop_caches: Permission denied |
|
Sure, under OS-level virtualization with faux root. That, in fact, is the consequence of the MAC I've been talking about, enforced by the host kernel. Thanks for showing another example where MAC is the proper way to do policy. |
|
| Back to top |
|
|
mv
Watchman
Joined: 20 Apr 2005
Posts: 6749
|
| Posted: Wed Apr 08, 2015 11:59 am Post subject: |
|
|
| ulenrich wrote: | | Computing is all about communication between different tasks. |
Please look up a definition of "computing" and do not invent some nonsense.
The communication between different tasks is rarely needed (unless you parallelize some computation, but this is a completely different story).
Essentially, it is only input/output of some data streams to fixed files/devices (and not to tasks!) which is sometimes used, but this usually happens before or after "computing".
| Quote: | | Normally there is ever and ever such talk between components. |
There are some system calls which must be implemented. Yes, if the concept of system calls would turn out to be vulnerable (e.g. if there would be a kernel bug which could confuse it in "knowing" your uid) or if the implementation of system calls would be faulty (e.g. if there would be a kernel bug which under some circumstances would open devices even without proper permissions), you have a severe problem.
There is nothing like absolute security.
However, one should do everything to limit this risk as far as possible: You cannot avoid that bugs in the kernel can make your system insecure. But this is no excuse to extend the risk in a completely unsane manner so that bugs in practically every component of a very complex system can make your system insecure. This is what systemd&friends are doing.
| Quote: | | Claiming "sudo" is a secure alternative is the most dangerous claim one can make. |
This is probably the most stupid sentence which I ever heard in a discussion about polikit. You really seem to have no clue how "sudo" can be used safely.
| Quote: | | Normal non experts should not try to configure "sudo" on a secured system. |
Normal non experts should not configure a system at all.
| Quote: | | To make "sudo" talking to your machine in a secure way you need a level of expertise. |
As you need for any administration task.
I understand your viewpoint, which is the pure salesman viewpoint: Every idiot should be able to administer the system without the slightest idea what he is doing.
This is exactly the windows philosophy, but as in windows, this is nothing but a sure receipt to produce further botnet power. And as a side result, as in windows, it makes it impossible to the skilled people to run a safe system without the insanity to sacrifice all sane security measurements for the idiots' convenience.
| Quote: | | but dbus messaging between equal privileged users only? |
I don't remember that I ever used the term "equal privileged" or something similar. Maybe between processes of the same user. But I do not remember any such discussion; in fact, I can hardly imagine that I ever suggested that dbus has any good use at all.
| Quote: | | Now think one of these users has a valueable "sudo" privilege without any password |
If this is so, the users are certainly not "equal privileged", by definition.
| Quote: | | Also the premise it is all about communication between unprivileged and privileged partners is flawed: In the real world you often cannot decide what role in effect is the more privileged. |
Everything which runs with root permissions is high privileged. So just practically everything which is system+polkit+... is high privileged. Now that was easy. Your strawman whether somethiing in addition might be exploited which runs with lower privileges than root is rather irrelevent when already a gigantic bulk of software with more than enough exploits runs with root permissions. |
|
| Back to top |
|
|
mv
Watchman
Joined: 20 Apr 2005
Posts: 6749
|
| Posted: Wed Apr 08, 2015 8:55 pm Post subject: |
|
|
| GrueXYZ wrote: | | While Polkit itself may have been badly implemented, a mechanism like that is definitely required |
"Required" needs an object: Required for/to(?) ...
It is not required to run a safe home machine.
It is not required to run a safe desktop.
It is not required to run a safe laptop.
It is not required to run a safe server.
Maybe there are some exceptional usages (A PC pool with mixed users and dialup connection) where something else might be useful. But then the administrator of such a huge pool (who should better be competent anyway), has to evaluate carefully whether the enormous inherent risks of this "something else" outweights the inconcenveniences for the users.
And more imporant: Why should those users who just want to run a home machine/deskop/laptop/server be also forced to these risks?
| Quote: | | Then again we do have MACs (Mandatory Access Control) but those don't cut it either as they're conceptually not designed to control concurrency only context of access. |
Which in most cases is exactly what is wanted and needed.
Again: Some exotics settings/usages do not justify to break security of everybody's systems.
| Quote: | | Meanwhile, the notion that low privileged process should not talk to a high privileged one is pure nonsense. |
No. Such a risk should be avoided.
| Quote: | For instance, there is a difference between:
1. a lo-priv process being able to call and execute /usr/sbin/useradd
2. a lo-priv process telling some central authority that it needs user X, with properties Y and Z, with no ability to execute any code directly |
Both is a big mistake. Only root should have permissions to add a user.
Full stop.
That being said, the second is completely insane, because the former can simply be restricted, while talking to "central authority" is not restricted, and so any bug in the protocol or within the central authority can give the user unexpectedly much more permissions, possible even to users sthat hould not even have the right to call useradd.
Simply put: Having such a "central authority" is a gigantic risk which you should better not have at all.
| Quote: | | I think in 2015 we cannot deny the fact that relying groups, sudo and suids is insufficient. [...]a central authority that implements policies beyond DAC and MAC is definitely needed |
Again, there are the buzzwords "insufficient" or even "definitely needed". And for what is a sane setup "insufficient" and a complex monster instead "definitely needed"?
It is not required to run a safe home machine.
It is not required to run a safe desktop.
It is not required to run a safe laptop. [...]
Aha: It is required, because we have 2015.
| Quote: | | Also, sudo is a totally wrong concept in 2015. |
What strange things did happen in 2015 which suddenly make the safe concepts insecure and a complex system running with root permissions secure?
Ah, you tell us:
| Quote: | | It was designed to keep users at bay, in the times when the word "malware" and "trojans" did not exist. |
On obviously wrong information. Combined with absolute nonsense and FUD:
| Quote: | | Executing a trojaned bin with sudo |
If that particular binary, provided by the administrator with root permissions, can be a trojaned bin, we need not discuss anymore about security, because either the administrator himself has installed this trojan or $BAD_GUY has already got root permissions before. |
|
| Back to top |
|
|
229566
Tux's lil' helper
Joined: 16 Aug 2010
Posts: 127
|
| Posted: Wed Apr 08, 2015 10:53 pm Post subject: |
|
|
| mv wrote: |
Both is a big mistake. Only root should have permissions to add a user.
Full stop.
|
That's not true and there are hundreds of thousands of cPanel servers that prove you wrong. A cPanel reseller account is able to click and add a cPanel account which in turn creates a system user. A cPanel reseller account does not have root privilege on the server.
In a similar admin environment that WE use (we don't use cPanel but a home grown system), it's really simple. A lo-priv process creates a task - it wants a user account created. A central authority daemon is listening to such tasks being created (via database pub/sub or eg. ZeroMQ). The daemon is isolated and runs as root.
Can the system be exploited so that an attacker creates a system account? Yes. But there's no way to avoid that except make it as hard as possible for that vector to be attacked. Speaking in car analogies, removing that vector altogether would be like removing key ignition from a car because a thief might crack it and take off with the car.
| Quote: | | That being said, the second is completely insane, because the former can simply be restricted, while talking to "central authority" is not restricted, and so any bug in the protocol or within the central authority can give the user unexpectedly much more permissions, possible even to users sthat hould not even have the right to call useradd. |
Absolute nonsense.
A pub/sub model with well defined interfaces is all you need. The worst that can happen in the above case is an attacker creating a system account but those are by default made with nologin which requires an admin to manually elevate. The attacker cannot create a task to download and install latest rootkit because there is no such task.
Exchanging (text) messages is far more benign than sudoing a binary.
| Quote: |
If that particular binary, provided by the administrator with root permissions, can be a trojaned bin, we need not discuss anymore about security, because either the administrator himself has installed this trojan or $BAD_GUY has already got root permissions before. |
Nope. Since this is a Gentoo board, all you need is to poison a mirror. I take it that good part of the gentoo userbase --syncs without verifying the signature. But even a signed bin can be trojaned. It has happened before, I personally remember Fedora and OpenSuse servers being compromised many years ago.... The point being, you don't need root access on a server to trojan it. |
|
| Back to top |
|
|
steveL
Watchman
Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery
|
| Posted: Thu Apr 09, 2015 6:55 am Post subject: |
|
|
| GrueXYZ wrote: | | A pub/sub model with well defined interfaces is all you need. |
Well (k)dbus ain't it. As discussed to death in several other threads already, TIPC is it.
| mv wrote: | | If that particular binary, provided by the administrator with root permissions, can be a trojaned bin, we need not discuss anymore about security, because either the administrator himself has installed this trojan or $BAD_GUY has already got root permissions before. |
| Quote: | | Nope. Since this is a Gentoo board, all you need is to poison a mirror. I take it that good part of the gentoo userbase --syncs without verifying the signature. But even a signed bin can be trojaned. It has happened before, I personally remember Fedora and OpenSuse servers being compromised many years ago.... The point being, you don't need root access on a server to trojan it. |
Yes, but mv's point is if it's trojaned anyway, wtf good is all this other crap going to do?
And when the admin is halfway competent, including knowing when to leave well enough alone, a traditional UNIX setup without all the fandango, suffices for all the use-cases the systemdiots are supposedly aiming this "convenience" at, most especially every single desktop, laptop and gadget user out there.
The conventional approach is also much more secure, or we wouldn't have a banking-system, let alone an internet.
So in summary, systemdbug is insecure by design, adds a shedload of work for everyone, and doesn't even add value for the core userbase.
Nor does it for the serious admin, who won't touch such a convoluted mess which they cannot stake their reputation on, because it is simply too complex in its desire to be the One True Init, and far too inflexible with its amateur-hour rejection of modularity.
All it does is enforce a GPL-evasion mechanism across the mainstream Linux install base, and serve the user up as a product to be monetised.
Oh, and finally make Linux catch up with Windows; in the area of security, that is.
We do not want to "make it impossible for the skilled people to run a safe system without the insanity to sacrifice all sane security measurements for the idiots' convenience." Let's leave that to others, if they really must.
Meantime the rest of us idiots can rely on "old" software that's "bit-rotted" because no-one needs to change it, and a sane permission model that is transparent, and protects us in general usage. |
|
| Back to top |
|
|
mv
Watchman
Joined: 20 Apr 2005
Posts: 6749
|
| Posted: Thu Apr 09, 2015 7:20 am Post subject: |
|
|
| GrueXYZ wrote: | | mv wrote: |
Both is a big mistake. Only root should have permissions to add a user.
Full stop.
|
That's not true and there are hundreds of thousands of cPanel servers that prove you wrong. |
A nice example which shows that there might be very particular settings where the advantage (the possibility to sell accounts) might outweight any risk: It is completely unnecessary for most systems, and it would be completely inappropriate to establish such a possibility with the inherent risk for private laptops, desktops, etc.
For the particular purpose, a safe setup is of course not to give unlimited access to adduser via sudo, as you seem to suggest, but to give unlimited (execute) access (e.g. via sudo) to a particular hand-crafted program which takes exactly one parameter (the username), does a sanity check with that parameter, logs, etc., and eventually calls adduser with correct groups etc.
| Quote: | | But there's no way to avoid that except make it as hard as possible for that vector to be attacked. |
Exactly. Therefore, write this single hand-crafted program very carefuily, checking all corner cases. And do not put this functionality as a small part of some huge root daemon/script, which, when given other parameters, can also mount your USB stick or cook your coffee. Isolate the attack vectors and, especially, do not introduce any other than those which are absolutely needed.
| Quote: | | Nope. Since this is a Gentoo board, all you need is to poison a mirror |
Completely unrelated strawman. It has nothing to do with sudo.
Yes, if the distribution you install is corrupted and you do not realize it, all other security measurements are in vain.
Do you really want to use the fact that there also exist always some attack vectors as an excuse to run an unsafe systems? |
|
| Back to top |
|
|
229566
Tux's lil' helper
Joined: 16 Aug 2010
Posts: 127
|
| Posted: Thu Apr 09, 2015 10:34 am Post subject: |
|
|
| mv wrote: | | For the particular purpose, a safe setup is of course not to give unlimited access to adduser via sudo, as you seem to suggest, but to give unlimited (execute) access (e.g. via sudo) to a particular hand-crafted program which takes exactly one parameter (the username), does a sanity check with that parameter, logs, etc., and eventually calls adduser with correct groups etc. |
Which is a tremendous additional, and quite unnecessary burden to maintainers and system integrators (because software makers won't do it, since they haven't already), or to administrators if their distro doesn't come with those "hand crafted programs". And it fragments important policy making process into several "hand crafted programs" instead of having a centrally management configuration option for a policy daemon with a well-defined API.
And that's without having to decide how to deploy such policies across many machines with different privilege levels across different networks. Because no, "installing Puppet (or whatever)" doesn't cut it. It's one of many CM apps and it's basically delegating important OS-level decision making to complex third party apps. Because the management and decision makers in the company will opt for Windows that does it centrally, instead of having to re-educate employees in case their Puppet admin quits and they can only hire Salt admins.... Linux? That's a toy, we can't use that for serious business, they say.
How about different times of day having different sets of policies involved. No, you can't run Steam because it's past nine and you should be in bed. I'm not kidding. And that's not even lo-priv - hi-priv access, but a central policy forbidding user X to run Steam, as that user, with no sudo involved...
Hardware. Different hardware present having different sets of policies involved. IP address defining a set of policies you enforce. WiFi network name. Etc... Do these hand-written programs all account for such policies? Does a "hand written program" need to know in advance all the possible combinations of hardware it will be run on, in order to specify how the policy is changed?
Example? Your lo-priv laptop user can print over network only if the IP is in subnet X (but otherwise can surf the net just fine). Oh also? The webcam can't be enabled unless in that subnet too. Oh wait, wait, we disable plugable USB devices except mouse and keyboard unless the laptop is in subnet X. Good luck coaxing individual package developers to implement all those policies in their application configuration. Good luck coaxing distro maintainers to write the "hand crafted programs" to deal with that, for each individual program that might be used in such a context.
Also, do we today have the ability where a critical running app (say a backup program) instructs the OS to disallow eg. suspension without asking the user whether they really want it, since the critical process is still running? And I mean a popup like "Oh, hai, you wanna suspend but wait, I'm still running and I shouldn't be interrupted. What do you wanna do?". Oh, the laptop lid was closed? Sound an alarm, start beeping and refuse suspending until it's acknowledged. And no, this needn't be absolute, but configurable. The user can configure their laptop to do that, or not.
How many times I've suspended the machine and regretted it because I had ssh sessions open, and once even a backup process running, and I just forgot about them. How many times I wished the computer would popup a dialog saying I have those running, am I sure I want to suspend.
None of the existing DAC or MAC/RBAC subsystems can do that. User/groups policy alone cannot do that.
I never said PolicyKit itself was a solution I only acknowledge the problem that requires policies beyond users and groups.
SteveL,
I never said (k)dbus ITSELF were the solution, I only acknowledge that message-passing instead of executing code at the CPU level, is the proper way to do lo-priv <-> hi-priv communication. Such mechanism can establish a policy and then create and give access to sockets and file descriptors for actual data transfer. Sure, I think that sending audio or video through (k)dbus messages is beyond insane. |
|
| Back to top |
|
|
ulenrich
Veteran
Joined: 10 Oct 2010
Posts: 1480
|
| Posted: Thu Apr 09, 2015 11:38 am Post subject: |
|
|
@mv, thank you for deeply going into it.
/me hanging around with "bundled" systemD+dBus+policyKit
I will further examine if it can be "secured", which you claim not possible. But the whole rest of the Gnu-Linux community thinks they can rely on (a few mini communities an exception). I still cannot believe it, also you have argued already to me this kind of thing happened before: A whole industry of small businesses relying on a known to have flaws architecture (Windows small business server). Maybe there is a technique behind the curtain giving perfect security: systemD uses CapabilityBoundingSet restrictions | Code: | # grep CapabilityBoundingSet *.service
bluetooth.service:CapabilityBoundingSet=CAP_NET_ADMIN CAP_NET_BIND_SERVICE
dbus-org.freedesktop.hostname1.service:CapabilityBoundingSet=CAP_SYS_ADMIN
dbus-org.freedesktop.login1.service:CapabilityBoundingSet=CAP_SYS_ADMIN CAP_MAC_ADMIN CAP_AUDIT_CONTROL \
CAP_CHOWN CAP_KILL CAP_DAC_READ_SEARCH CAP_DAC_OVERRIDE CAP_FOWNER CAP_SYS_TTY_CONFIG
...etc |
And second it might also worsen the FLOSS power: | steveL wrote: | | All it does is enforce a GPL-evasion mechanism across the mainstream Linux install base, and serve the user up as a product to be monetised. |
Android users are affected of exactly this since years. The Google "Binder" ipc mechanism has just seen the light of Linux kernel mainline. Otherwise, hearing Ms talking about to open source, there are a whole lot of forces driving the industry. And there are DRM bounds for users regarding content not directly related to computing source code. |
|
| Back to top |
|
|
mv
Watchman
Joined: 20 Apr 2005
Posts: 6749
|
| Posted: Thu Apr 09, 2015 3:12 pm Post subject: |
|
|
| GrueXYZ wrote: | | mv wrote: | | For the particular purpose, a safe setup is of course not to give unlimited access to adduser via sudo, as you seem to suggest, but to give unlimited (execute) access (e.g. via sudo) to a particular hand-crafted program which takes exactly one parameter (the username), does a sanity check with that parameter, logs, etc., and eventually calls adduser with correct groups etc. |
Which is a tremendous additional, and quite unnecessary burden |
Your assertion is a great nonsense.
If you want to offer this particular service you have to think about the exact policy (in which groups should such users be put, which shell will they get, which limitation on the number of users produced in such a way do you put etc) and you have to describe all the details of this poliy in some language.
| Quote: | | And it fragments important policy making process into several "hand crafted programs" instead of having a centrally management configuration option for a policy daemon with a well-defined API. |
And again a completely wrong assertion. The difference in the maintainer's work between the sane (sudo - A) approach and the unsane (policykit - B) approach is:
A) You write a hand-crafted program/configuration in a language of your choice
B) You write a hand-crafted program/configuration with exactly all the same checks in the language of the policy daemon
So, usually, B causes even more work, because you are unnecesssarily restricticted in the choice of the language and configuration.
In addition you open a completely superfluous attack vector by having a completely superfluous complex monster running with root permissions.
Your strawman about net-distribution with/without puppet or however is the same for A and B.
I see just that you ignore the work of B and claim that the simpler work of A - which is the native administrator's task - be a tremendous unnecessary burden.
Please, do never think about administrating my systems! Thank you. |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
Gentoo Chat
