|
Kevin Mitnick P.E. posted:edit: snowden was a sysadmin. with selinux he should be able to cj poo poo w/o being able to read the TOP SECRET .nfos. but selinux is such a horrible pita to set up for that poo poo that no one bothers, apparently not even the organization with the greatest need for it it would be really, really hard to use selinux to hide anything from your CJs. that's not really what it's for. what selinux is really good for is constraining applications. get a buffer overflow on apache? congratulations, you can listen on port 80 and open files readonly in /var/www. you achieved uid=0, but your uid doesn't entitle you to anything because of your selinux-constrained process.
|
#
?
Jul 24, 2014 04:06
|
|
|
|
| # ? May 27, 2024 07:18 |
|
|
Kevin Mitnick P.E. posted:wow yeah that has nothing at all in common with COM. well there is one difference i guess, dbus needs a daemon to do what COM does The thing that DBus does that COM doesn't, which is the whole point of the "bus" here, is late binding and service registry/discovery. COM allows you to do inter-process communication once you've established that link, but doesn't allow you to find a link to establish in the first place. The goal of this is to build replaceable components with well-defined interfaces. So, for instance, all the notification system is is a single interface, org.freedesktop.Notifications, and it can be implemented by any system: notification-daemon, notify-osd, KDE's plasma, and it's all interoperable. There's other standardized components, too, and there's plenty of useful services on the bus.
|
|
#
?
Jul 24, 2014 04:17
|
|
|
kraftwerk singles posted:Not surprisingly the same people who worked on GNOME created DBus. The DBus C API is such a pile of poo poo that they have to get someone else to wrap their API to make it usable. But of course they make it into a DBus-GLib which still loving sucks because you have to use GObjects and poo poo. The original intention behind the client libraries was that they were intended to be wrapped: GLib would construct GObjects out of them, Qt would construct QObjects out of them, Java would construct Java objects out of them, Python would construct Python objects out of them, etc. So DBus-GLib was already intended to be a thing when libdbus was created. I think that most people would say that that didn't turn out as envisioned, and that we should have focused on creating one strong solid C client library. Hindsight is 20/20.
|
|
#
?
Jul 24, 2014 04:22
|
|
|
kraftwerk singles posted:Lol please don't mix the worst computer forum on the internet with the other worst computer forum on the internet
|
|
#
?
Jul 24, 2014 04:24
|
|
|
Suspicious Dish posted:COM allows you to do inter-process communication once you've established that link, but doesn't allow you to find a link to establish in the first place. isn't that CoGetClassObject, basically?
|
|
#
?
Jul 24, 2014 04:26
|
|
|
Suspicious Dish posted:The thing that DBus does that COM doesn't, which is the whole point of the "bus" here, is late binding and service registry/discovery. gnome had already solved this problem with OAF. OAF was basically JNDI for gnome's CORBA stuff. it let you look up where the thing you wanted was gonna be, then you reached out to it via your normal gnome object broker.
|
|
#
?
Jul 24, 2014 04:26
|
|
|
Suspicious Dish posted:So DBus-GLib was already intended to be a thing when libdbus was created. I think that most people would say that that didn't turn out as envisioned, and that we should have focused on creating one strong solid C client library. Hindsight is 20/20. no one seems to have learned that writing code with gobject is unpleasant
|
|
#
?
Jul 24, 2014 04:27
|
|
|
Notorious b.s.d. posted:no one seems to have learned that writing code with gobject is unpleasant It's more pleasant than C++.
|
|
#
?
Jul 24, 2014 04:33
|
|
|
Subjunctive posted:isn't that CoGetClassObject, basically? I'm not aware of any mechanism in COM that allows multiple vendors to implement some specific interface and register it against a global name. CLSIDs, from my understanding, are supposed to be globally unique identifiers, and it's considered really broken for two different vendors to install the same CLSID.
|
|
#
?
Jul 24, 2014 04:39
|
|
|
Suspicious Dish posted:I'm not aware of any mechanism in COM that allows multiple vendors to implement some specific interface and register it against a global name. CLSIDs, from my understanding, are supposed to be globally unique identifiers, and it's considered really broken for two different vendors to install the same CLSID. yes but dbus was not replacing com. it was replacing bonobo/corba. and bonobo/corba did indeed have a way to register an interface against a name: oaf.
|
|
#
?
Jul 24, 2014 04:54
|
|
|
Suspicious Dish posted:It's more pleasant than C++. java-gnome should have been the future
|
|
#
?
Jul 24, 2014 04:54
|
|
|
suffix posted:please don't mix the worst computer forum on the internet with the other worst computer forum on the internet 
|
|
#
?
Jul 24, 2014 04:57
|
|
|
Notorious b.s.d. posted:it would be really, really hard to use selinux to hide anything from your CJs. that's not really what it's for. why is a root process listening on a port. besides which idgaf if someone pwns a box. is customer data compromised? how does selinux prevent that, the actual thing that is a problem it's also horribly complicated and customizing it is poorly documented and generally terrible. but i think i mentioned that already
|
|
#
?
Jul 24, 2014 05:13
|
|
|
he's saying that an apache process that's been compromised and has managed to escalate its privileges won't be able to read customer data unless some idiot symlinked it into /var/www. selinux is all about reducing attack surface.
|
|
#
?
Jul 24, 2014 06:36
|
|
|
suffix posted:please don't mix the worst computer forum on the internet with the other worst computer forum on the internet phoronix or arse?
|
|
#
?
Jul 24, 2014 08:01
|
|
|
Suspicious Dish posted:The thing that DBus does that COM doesn't, which is the whole point of the "bus" here, is late binding and service registry/discovery. this is exactly what com and com+ solve btw late bind to interfaces via guids more or less unfortunately there is only like one person who understands com
|
|
#
?
Jul 24, 2014 08:32
|
|
|
do you mean charles petzold or mark russinovich
|
|
#
?
Jul 24, 2014 13:36
|
|
|
Otto Skorzeny posted:do you mean charles petzold or mark russinovich don box
|
|
#
?
Jul 24, 2014 14:03
|
|
|
Malcolm XML posted:don box the man with IUNKNWN on his license plate
|
|
#
?
Jul 24, 2014 14:03
|
|
|
don box worked with dave winer once; he's dead to me.
|
|
#
?
Jul 24, 2014 14:10
|
|
|
|
|
#
?
Jul 24, 2014 14:12
|
|
|
Suspicious Dish posted:I'm not aware of any mechanism in COM that allows multiple vendors to implement some specific interface and register it against a global name. CLSIDs, from my understanding, are supposed to be globally unique identifiers, and it's considered really broken for two different vendors to install the same CLSID. there is no reason for doing what you're talking about because it would be far too easy to stick a hosed up implementation into the global namespace that a client is using. However there would be plenty of ways to implement your own global namespace on top of com. Either by enumerating all com objects and finding the ones w/ matching sigs (probably bad idea), or by having one com server that handles registration of other services that implement the desired interfaces. then the clients request information about the implementation services from the registration service. this is probably a much better idea than whatever dbus does because it would also allow the registration service to handle additional tasks during registration (like maybe security checks, or validation of implementation, or uptime handling which would probably be useful for dcom services). altho there may already be a way to do that w/ com, but I've never used anything beyond really basic stuff
|
|
#
?
Jul 24, 2014 14:24
|
|
|
YOSPOS posted:microsoft screwed up standardised ipc, standardised persistent settings, record-structured system logging, bitmap-based remote display, and service management. let us never attempt any of these things.
|
|
#
?
Jul 24, 2014 14:25
|
|
|
Suspicious Dish posted:The thing that DBus does that COM doesn't, which is the whole point of the "bus" here, is late binding and service registry/discovery. in COM you would have a notification service with methods for a consumer to register for events or to send events and the com service handles receiving and distributing events. theres no reason for the senders or consumers to even be com services at all, so idk why you'd want to stick them in com with overlapping interfaces for no real reason.
|
|
#
?
Jul 24, 2014 14:27
|
|
|
Malcolm XML posted:this is exactly what com and com+ solve btw except you have to give COM a CLSID and not an IID, right? you'd have to roll your own thingy to find the CLSIDs implementing a given IID, which dbus does for you
|
|
#
?
Jul 24, 2014 14:27
|
|
|
that's stupid though because that's not something you'd ever want to do. in dbus you've not got to be super protective about everyone you talk to because you have no idea if they did the thing right and you and every other similar system is gonna be constantly looking for new implementations of the interface. then even when its working you're gonna have a million objects firing each of their messages between each other which is a mess.
|
|
#
?
Jul 24, 2014 14:30
|
|
|
The biggest problem in windows is how wildly successful and good COM is because it means as long as windows still supports whatever win 3.11 runtime your finance system uses, you're new .net 4.5 web app can get to it thru COM.
|
|
#
?
Jul 24, 2014 14:32
|
|
|
naw man the point is that some app will depend on the interface and dbus handles supplying the implementation. not that on a given system theres more than one implementation, it means you can have apps that work cross-desktop-environment because they talk to org.freedesktop.Notification instead of the GNOME notification thingy, the KDE notification thingy, the XFCE notification thingy, etc loose coupling y'know like yes you can do this with COM but you have to roll your own which means every implementation will be different and a special snowflake of shittiness so i was wrong, dbus is just bad which is nothing to complain about
|
|
#
?
Jul 24, 2014 14:39
|
|
|
but that's not really true because this is Linux and everyone wants to have their own custom implementation of org.freedesktop.Notification regardless of windowing system or distro so theres no guarantee the client will ever know whats on their and multiples are guaranteed to get installed as the Linux user tries out every window manager under the sun before going back to windows. you still have custom snowflake implementations of the service, but you have no idea which one you're using and each installer is gonna replace itself as the registered notification implementation. in the com solution I mentioned about you have a guaranteed implementation of the service and the notify and subscribe methods. effectively making the service a relay of notification methods with a specific format. this is probably actually already done in some other part of windows tho so com is probably not the place for it.
|
|
#
?
Jul 24, 2014 14:49
|
|
|
dbus does what nintendont
|
|
#
?
Jul 24, 2014 14:49
|
|
|
DNS: A Bad Idea
|
|
#
?
Jul 24, 2014 15:06
|
|
|
observer pattern is taking a beating in this thread
|
|
#
?
Jul 24, 2014 16:41
|
|
|
Kevin Mitnick P.E. posted:why is a root process listening on a port. it's not. what i'm saying is that if your apache is compromised, AND the attacker uses a root-escalation bug, it still doesn't matter. the entire apache process tree is constrained such that uid 0's only special privilege is opening port 80. in other words, getting root on the box doesn't actually win the attacker anything. Kevin Mitnick P.E. posted:besides which idgaf if someone pwns a box. is customer data compromised? how does selinux prevent that, the actual thing that is a problem when someone "owns the box" he only owns apache. he doesn't have a launchpad and safe haven on your network from which to scan for other vulnerabilities and make a minor security breach into a major one.
|
|
#
?
Jul 24, 2014 17:00
|
|
|
Notorious b.s.d. posted:it's not. what i'm saying is that if your apache is compromised, AND the attacker uses a root-escalation bug, it still doesn't matter. the entire apache process tree is constrained such that uid 0's only special privilege is opening port 80. not worth the effort of selinux imo
|
|
#
?
Jul 24, 2014 17:01
|
|
|
Kevin Mitnick P.E. posted:you mean the actual security problem...is people??? silly example: how is a MAC-enabled operating system going to prevent you from copying secret data to an external drive, if the machine is currently powered off and the secure os isn't running? classic MAC is absolutely useless in a networked environment, with removable storage or with "legacy" applications (i.e. over 50 years of commercial applications without exception). security labels don't go deep enough and they probably can't. in the 70s you could probably get away with storing everything side-by-side on the mainframe's disk array, and you could conceivably give a clearance label to each I/O device (terminals, printers, modems, etc.) since in the end it all was just a bundle of serial cables plugged in a single bus, but what about tyool 2014? web browsers in particular are tiny little operating systems on their own, and no existing browser has a security model that can be made compatible with MAC. browsers sandbox websites at best, but they let a website mix and match content from several different sources. even if you had a way of reliably labeling network connections (or better, reliably labeling HTTP resources, which you have about zero hope to), the best you could end up with would be a broken site, with resources that don't load because they're above your clearance or forms that don't post because the destination is below your clearance. you'd have to run every single domain in a separate process, and no current browser does that (although a paper floated around years ago). that's still no solution: how exactly you'd prevent propagation of information in a web page? any single resource you add to the page could affect the whole page. you could serve a whole site under a single label and forbid external resources, but then you'd need a separate server for each clearance/compartments combination, or give a web server a multi-label identity and (haha) trust it not to leak information across compartments or up/down the clearance scale, which is hopeless because no commercial web server has ever been designed to do that. plus mixing multiple compartments and clearances in the same subject (in exceptional circumstances you need services/users with this privilege so that e.g. you can release declassified copies of documents) is not bad practice, it's the worst practice MAC was hard enough to implement in the 70s, nowadays it's pretty much hopeless. all effort so far has been put into integrity rather than access control, and even then with imperfect implementations. think of how many privileged services have been exploited with corrupted data coming from a lower privilege: sure full mandatory integrity control would have stopped those attacks (the "no write up" rule), but then you'd lose the ability to send unprivileged data (like say, a configuration file or the description of a task to execute) to privileged processes entirely (djb is the single programmer in the world who knows and cares about this stuff). similarly, any implementations of access control you're realistically going to deal with are missing a strong "no write down" rule (clearance levels are the mirror image of integrity levels), which is how leaks happen
|
|
#
?
Jul 24, 2014 17:02
|
|
|
Shaggar posted:but that's not really true because this is Linux and everyone wants to have their own custom implementation of org.freedesktop.Notification regardless of windowing system or distro so theres no guarantee the client will ever know whats on their and multiples are guaranteed to get installed as the Linux user tries out every window manager under the sun before going back to windows.
|
|
#
?
Jul 24, 2014 17:05
|
|
|
in fact, I was thinking while on the toilet: how the hell would you go about segregating a relational database by clearance?
|
|
#
?
Jul 24, 2014 17:18
|
|
|
kraftwerk singles posted:Lol Thank you for sourcing your quotes. augh
|
|
#
?
Jul 24, 2014 17:56
|
|
|
hackbunny posted:classic MAC is absolutely useless in a networked environment... this is a good post
|
|
#
?
Jul 24, 2014 17:57
|
|
|
|
| # ? May 27, 2024 07:18 |
|
|
I think part of it is that we implement MAC for all of the "filesystem", and the filesystem has a combination of user data, application data, operating system internals and data, raw device access, internal system state, and more. I certainly don't think you can build a good security model around this data structure where we've stuffed literally everything into it. I think MAC makes sense for user data, where you really want to guarantee that user data can't be accessed by unprivileged users, be them friends, attackers, or other apps. The user should make the explicit choice to share it with their friends, or upload it to the web. But the same system that makes sense for MyTopSecretData.doc certainly won't also make sense for /dev/cdrom, because the use cases don't have anything in common. Here, you need applications to be able to request access to the CD ROM drive, and enforce some policy in a passive manner. The app won't ever need to share the CD ROM driver or upload the CD ROM to the web. You have an app that's accessing a global device, not a user trying to open a document. The way we solve this is by having some crazy combination of flexible rules to enforce policy in a terrible way, which ends up loving over the user, who has no transparency into why this complex policy aren't letting him copy data onto his flash drive, so he goes ahead and disables the entire system, because he needs to get poo poo done. The only proper way to this is to stop shoving user data and system internals in the same data structure, and provide a clear separation and a clear user model.
|
|
#
?
Jul 24, 2014 18:07
|
|